[GEM-dev] osx fullscreen changes survey

[james tittle]

allo,

On Aug 14, 2005, at 10:47 AM, cyrille henry wrote:
> sorry, i forget to reply to this mail earlier.
>
> maybe it's to late, but : I just have a 1 commment about 'esc' and  
> exiting fullscreen.

...never too late with my development habits :-)

> I know that it's frustrating to have the gemwin fullscreen without  
> any solution to close it. this is why i don't use gemwin, but an  
> abstraction   composed with gemwin and gemkeyname / select escape /  
> destroy

...perhaps we should incorporate this into the Gem/abstractions  
directory?  Convenience patches like the one you mention are highly  
sought after, especially if we can start using them in the  
documentation to further enforce a kind of "best practices"...

> yes, pressing 'esc' is standard for game to exit fullscreen mode,  
> but it is not standard for interactive installation (where the gem  
> windows should not be destroy).
> i think gem is more used for interactive instalation than for game  
> developement...
>
> another exemple : imagine that you press the esc key during a  
> performance while trying to find the F1 key. it's scarry for me to  
> have such feature.
>
> i think it really would be nice if the 'esc' -> exit feature is not  
> coded inside gem, but inside user patch (like i curently do).
>
> so, please : do not code the esc to exit fullscreen.

...ok, yr voice of reason rules:  there's really no good reason to  
hard code this to any particular key, that would defeat the whole  
flexibility-thing we hold so dear in pd...so now I'm thinking to just  
add a new message to gemwin for "menubar":

[menubar 1< shows
[menubar 0< hides

...another thing to consider here is disabling the osx dock and cmd- 
tab application switching:  these could also be turned on/off in  
tandem with the menubar message, or there could be a "kiosk"  
message...?  The same api I'm using to do this allows broad  
capabilities to locking out users from the computer (ie. no force- 
quit applications, no powering down via keyboard, etc)

...this is probably only applicable/necessary to osx, right  
(anyone)?  It is also possible to put in a third state, where the  
menubar pops up when the mouse cursor goes to the top of the screen  
(like in apple's dvd player fullscreen mode):  I'm thinking I'll put  
this as default for "fullscreen on main display" mode, that way if  
you forget to make a key attached to the menubar message, you can  
still bring it up...

...btw, looking at the gemwin code I see that we're getting quite a  
few messages:  fullscreen, secondscreen, offset, border and dimen all  
have to do with these nuances of window behavior...refresh my memory,  
but is "secondscreen" even necessary anymore?  Doesn't [fullscreen 2<  
do similar (or should)?

...ok, back to coding :-)

jamie

>
> james tittle a écrit :
>
>> hey,
>> ...well, it had to happen sometime!  I've finally come around to  
>> a  need for a 'kiosk'-like presentation via gem, on a single  
>> monitor/ touchscreen...we've been a bit conservative in allowing  
>> this, because  without the proper foresight/design, it's  
>> incredibly easy to lock  yourself out of the computer, and thereby  
>> require a hard restart :-)
>> ...so, I'm going to go ahead and make it possible in a coupla   
>> different ways, but I also want to have an easy way to get out of   
>> it...basically, I'm talking about taking over the escape key,  
>> such  that whenever we're in fullscreen or fullscreen-windowed  
>> mode,  hitting the escape button will destroy the window...there  
>> is a  caveat:  this will only always work in my pd++.app (or  
>> derivations  thereof), because keyboard input in gem is dependent  
>> on the gem  window being front "focused"...
>> ...I think the best way to do this is two pronged:
>> 1.  a "fullscreen 1" message will capture the main device, hiding  
>> the  dock/menubar/option-tab application selector...it'll also  
>> always  cause the window to be "focused", so 'esc' will always  
>> work...plus,  in this state we control the VRAM, so we can manage  
>> that better...
>> 2.  creating a window the size of the screen without a fullscreen   
>> message, and without an offset to another device, would also  
>> cover  the screen, and either automatically turn off the dock/ 
>> menubar/option- tab-selector, or do so by another message
>> ...does this sound ok?  I think using 'esc' for exiting fullscreen  
>> is  pretty standard in the gaming world and so would be an easy  
>> fit  here...In any event, I'll be doing it this weekend...
>> jamie
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>