[GEM-dev] osx fullscreen changes survey

B. Bogart ben at ekran.org
Mon Aug 15 21:04:44 CEST 2005


Hi Jamie,

Indeed lots'o' abstractions in gem would be really handy. I have not
tried Cyrille's abstraction yet, but if it includes things like the
super-handy click and drag in the gemwindow to "orbit" that would be
amazing. Looks like Cyrille did the trig to make a nice orbit using view
messages. How is the camera object going Jamie?

Actually Jamie, Id like to hear more about your kiosk project.

I think the "menubar" messages you suggest here look great. I also agree
it would be handy to have the menubar show up only when you move the
mouse to the top of the window in fullscreen mode.

I guess that could mean:

"menubar 0"
"menubar mouse" or "roll-over"?
"menubar 1"

Maybe...

"menubar 1" is the default and so you need to do "menubar 0, fullscreen
1" to lock yourself out. "fullscreen 1" on OSX will leave the menubar up?

I can't figure out if "menubar mouse" should make the menubar only show
up when the mouse is at the top, or if this should only happen when in
fullscreen mode. Seems that it makes more sense to make it consistant
and so the menubar shows up on fullscreen by default, and you need to
turn it off manually... The idea of hitting "menubar mouse" and then
nothing happens seems awkward...

b>

james tittle wrote:
> 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
>>
>>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20050815/1e159da9/attachment.pgp>


More information about the GEM-dev mailing list