[GEM-dev] osx fullscreen changes survey

[cyrille henry]

james tittle a écrit :
> 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"...
> 

ok, here is the (GOP) abstraction I use.
it is a bit crappy, but works now for year.
i think it can be a good start if this kind of abstraction should be 
incorporated in Gem/abstraction.

cyrille

>> 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
>>
>>
> 
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
> 
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: _gemwin.pd
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20050815/f6c23f24/attachment.txt>