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:
- 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@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev