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
On Jul 29, 2005, at 3:35 PM, james tittle wrote:
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,
Sounds like a good idea!
it's incredibly easy to lock yourself out of the computer, and thereby require a hard restart :-)
Or you could ssh in and kill Pd, if you are on a network.
...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"...
You could also use [key], etc. or [hid] to get the key info, then that part would work in the regular Pd.app.
...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...
- 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...
Sounds good. I think its a broad standard for exiting fullscreen and other things.
.hc
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope."
-Edsger Dykstra
hello,
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.
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
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.
thanks Cyrille
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...
- 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
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
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
Quoting "B. Bogart" ben@ekran.org:
Hi Jamie,
I guess that could mean:
"menubar 0" "menubar mouse" or "roll-over"? "menubar 1"
i think that in "fullscreen" mode you generally do _not_ want the menu-bar at all. but if you want access to the menubar you could enable it (with "menubar 1") (this is: pop up the menubar when you put the mouse-pointer to the top of the screen) i don't think that there is a need to turn on the menubar permanently when in fullscreen mode.
so i'd think that "fullscreen 1/0" and "menubar 1/0" gives you all you need.
mfg.,a.sdr IOhannes
On Aug 16, 2005, at 10:04 AM, zmoelnig@iem.at wrote:
i think that in "fullscreen" mode you generally do _not_ want the menu-bar at all. but if you want access to the menubar you could enable it (with "menubar 1") (this is: pop up the menubar when you put the mouse-pointer to the top of the screen) i don't think that there is a need to turn on the menubar permanently when in fullscreen mode.
so i'd think that "fullscreen 1/0" and "menubar 1/0" gives you all you need.
...well, as you can tell in the commit, I went with a three-way selection...mainly because this stuff doesn't have to be done in fullscreen mode, but can be done anytime, which gives the possibility of having multiple applications available in "kiosk" mode (as long as the other apps also correctly turn off the menubar and stuff)...we're all about flexibility, right?
jamie
I think I have found a fix for the separator memory leak. It looks like there is really no case where the number of texture coordinates held in the GemState is ever not 4. So basically I put a check to see if the number of coordinates differ between the cached state and the passed GemState in the postrender function. If they differ it does the whole new allocation and the leak ensues, but I have yet to encounter a situation where that triggers.
I might be missing something rather big and obvious, so let me know before I commit this.
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
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:
- 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
#N canvas 117 68 381 307 10; #N canvas 141 41 975 650 init_gem__ 0; #X msg 211 333 create; #X msg 236 454 destroy; #X msg 193 380 1; #X msg 261 405 0; #X obj 236 382 t b b; #X obj 193 286 select 1; #X obj 64 463 r pos_cam; #X obj 411 46 inlet; #X obj 411 92 t b f b; #X obj 193 199 f; #X obj 660 42 inlet; #X msg 428 407 dimen $1 $2; #X msg 428 160 320 240; #X msg 445 183 640 480; #X msg 477 229 1024 768; #X msg 493 253 1280 1024; #X msg 660 180 0; #X msg 688 222 1024; #X msg 702 246 1280; #X msg 716 269 1400; #X msg 745 315 1920; #X msg 526 303 1680 1200; #X msg 510 278 1400 1050; #X msg 543 328 1920 1024; #X msg 730 291 1680; #X msg 222 200 0; #X obj 74 487 r reset; #N canvas 0 0 581 668 gemwin 0; #X obj 289 139 f; #X obj 210 120 spigot; #X obj 271 111 sel 0 1; #X obj 241 92 t f f; #X obj 210 168 -; #X obj 210 217 +; #X obj 271 181 f; #X obj 163 136 f; #X obj 84 117 spigot; #X obj 145 108 sel 0 1; #X obj 115 89 t f f; #X obj 84 168 -; #X obj 84 217 +; #X obj 145 178 f; #X obj 410 130 f; #X obj 331 114 spigot; #X obj 392 105 sel 0 1; #X obj 362 86 t f f; #X obj 331 165 -; #X obj 392 175 f; #X obj 84 433 * 4; #X obj 139 435 * 4; #X obj 160 276 t b f; #X obj 98 340 cos; #X obj 110 398 * 1; #X obj 84 398 * 1; #X obj 136 341 sin; #X obj 111 434 * 4; #X obj 98 362 t b f; #X obj 98 316 / 200; #X obj 84 459 pack f f f; #X obj 98 19 gemmouse; #X msg 84 484 view $1 $2 $3 0 0 0 0 1 0; #X obj 84 276 sin; #X obj 110 277 cos; #X obj 331 214 + 200; #X obj 161 250 / 50; #X obj 84 251 / -200; #X obj 24 24 inlet; #X obj 24 547 outlet; #X obj 25 519 gemwin $1; #X connect 0 0 4 1; #X connect 1 0 4 0; #X connect 2 0 6 0; #X connect 2 1 0 0; #X connect 3 0 1 1; #X connect 3 1 2 0; #X connect 4 0 5 0; #X connect 5 0 6 1; #X connect 5 0 29 0; #X connect 6 0 5 1; #X connect 7 0 11 1; #X connect 8 0 11 0; #X connect 9 0 13 0; #X connect 9 1 7 0; #X connect 10 0 8 1; #X connect 10 1 9 0; #X connect 11 0 12 0; #X connect 12 0 13 1; #X connect 12 0 37 0; #X connect 13 0 12 1; #X connect 14 0 18 1; #X connect 15 0 18 0; #X connect 16 0 19 0; #X connect 16 1 14 0; #X connect 17 0 15 1; #X connect 17 1 16 0; #X connect 18 0 35 0; #X connect 19 0 35 1; #X connect 20 0 30 0; #X connect 21 0 30 2; #X connect 22 0 21 0; #X connect 22 0 20 0; #X connect 22 0 27 0; #X connect 22 1 21 1; #X connect 22 1 20 1; #X connect 22 1 27 1; #X connect 23 0 28 0; #X connect 24 0 21 0; #X connect 25 0 20 0; #X connect 26 0 27 0; #X connect 27 0 30 1; #X connect 28 0 24 0; #X connect 28 0 25 0; #X connect 28 1 24 1; #X connect 28 1 25 1; #X connect 29 0 23 0; #X connect 29 0 26 0; #X connect 30 0 32 0; #X connect 31 0 8 0; #X connect 31 0 7 1; #X connect 31 1 1 0; #X connect 31 1 0 1; #X connect 31 1 14 1; #X connect 31 1 15 0; #X connect 31 3 17 0; #X connect 31 4 3 0; #X connect 31 4 10 0; #X connect 32 0 40 0; #X connect 33 0 25 0; #X connect 34 0 24 0; #X connect 35 0 19 1; #X connect 35 0 36 0; #X connect 36 0 22 0; #X connect 37 0 33 0; #X connect 37 0 34 0; #X connect 38 0 40 0; #X connect 40 0 39 0; #X restore 31 582 pd gemwin; #X msg 73 514 view 0 0 4 0 0 0 0 1 0; #X msg 660 358 $1; #X obj 660 408 * 1; #X obj 855 36 inlet; #X obj 854 173 sel 0 1; #X msg 854 198 1; #X msg 872 225 -1; #X obj 660 384 f; #X obj 855 73 t b f; #X obj 660 441 pack f 0; #X msg 660 474 offset $1 $2; #X obj 703 416 r offset_vertical; #X obj 428 136 select 0 1 2 3 4 5 6; #X msg 460 206 800 600; #X obj 660 502 t b a b; #X obj 193 60 r start_stop; #X msg 674 201 800; #X obj 660 137 sel 0 1 2 3 4 5; #X obj 44 421 inlet; #X obj 193 237 change 0; #X obj 193 355 delay 100; #X obj 193 260 speedlim 200; #X obj 236 427 delay 100; #X obj 195 309 t b b; #X msg 300 303 set create :0.1; #X msg 303 270 set create; #X obj 303 248 loadbang; #X obj 323 191 r create_2; #X obj 323 218 sel 0 1; #X obj 30 160 gemkeyname; #X obj 30 182 sel Escape; #X obj 29 228 + 1; #X obj 29 205 f; #X obj 30 249 % 2; #X obj 37 334 s start_stop_ext; #X obj 33 278 sel 0; #X msg 46 309 0; #X obj 430 440 s dim; #X obj 335 349 r gemwin; #X obj 336 369 route dimen; #X connect 0 0 27 0; #X connect 1 0 27 0; #X connect 2 0 27 0; #X connect 3 0 27 0; #X connect 4 0 50 0; #X connect 4 1 3 0; #X connect 5 0 51 0; #X connect 5 1 4 0; #X connect 6 0 27 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 8 1 40 0; #X connect 8 2 25 0; #X connect 9 0 47 0; #X connect 10 0 45 0; #X connect 11 0 27 0; #X connect 11 0 65 0; #X connect 12 0 11 0; #X connect 13 0 11 0; #X connect 14 0 11 0; #X connect 15 0 11 0; #X connect 16 0 29 0; #X connect 17 0 29 0; #X connect 18 0 29 0; #X connect 19 0 29 0; #X connect 20 0 29 0; #X connect 21 0 11 0; #X connect 22 0 11 0; #X connect 23 0 11 0; #X connect 24 0 29 0; #X connect 25 0 47 0; #X connect 28 0 27 0; #X connect 29 0 35 0; #X connect 30 0 37 0; #X connect 31 0 36 0; #X connect 32 0 33 0; #X connect 32 1 34 0; #X connect 33 0 30 1; #X connect 34 0 30 1; #X connect 35 0 30 0; #X connect 36 0 35 0; #X connect 36 1 32 0; #X connect 37 0 38 0; #X connect 38 0 42 0; #X connect 39 0 37 1; #X connect 40 0 12 0; #X connect 40 1 13 0; #X connect 40 2 41 0; #X connect 40 3 14 0; #X connect 40 4 15 0; #X connect 40 5 22 0; #X connect 40 6 21 0; #X connect 40 7 23 0; #X connect 41 0 11 0; #X connect 42 0 9 0; #X connect 42 1 27 0; #X connect 42 2 25 0; #X connect 43 0 9 0; #X connect 44 0 29 0; #X connect 45 0 16 0; #X connect 45 1 44 0; #X connect 45 2 17 0; #X connect 45 3 18 0; #X connect 45 4 19 0; #X connect 45 5 24 0; #X connect 45 6 20 0; #X connect 46 0 27 0; #X connect 47 0 49 0; #X connect 48 0 2 0; #X connect 49 0 5 0; #X connect 50 0 1 0; #X connect 51 0 48 0; #X connect 51 1 0 0; #X connect 52 0 0 0; #X connect 53 0 0 0; #X connect 54 0 53 0; #X connect 55 0 56 0; #X connect 56 0 53 0; #X connect 56 1 52 0; #X connect 57 1 58 0; #X connect 58 0 60 0; #X connect 59 0 61 0; #X connect 60 0 59 0; #X connect 61 0 60 1; #X connect 61 0 63 0; #X connect 63 0 64 0; #X connect 64 0 62 0; #X connect 66 0 67 0; #X connect 67 0 11 0; #X connect 67 1 27 0; #X restore 44 201 pd init_gem__; #X obj 70 51 vradio 15 1 0 8 empty empty empty 0 -6 0 8 -262144 -1 -1 0; #X obj 92 66 vradio 15 1 0 7 empty empty empty 0 -6 0 8 -262144 -1 -1 0; #X obj 108 49 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X obj 118 83 cnv 15 50 12 empty empty 800 0 7 0 14 -262144 -1 0; #X obj 118 97 cnv 15 50 12 empty empty 1024 0 7 0 14 -262144 -1 0; #X obj 118 112 cnv 15 50 12 empty empty 1280 0 7 0 14 -262144 -1 0 ; #X obj 118 126 cnv 15 50 12 empty empty 1400 0 7 0 14 -262144 -1 0 ; #X obj 118 141 cnv 15 50 12 empty empty 1680 0 7 0 14 -262144 -1 0 ; #X obj 118 156 cnv 15 50 12 empty empty 1920 0 7 0 14 -262144 -1 0 ; #X obj 119 67 cnv 15 50 12 empty empty 0 0 7 0 14 -262144 -1 0; #X obj 7 86 cnv 15 50 12 empty empty 800 0 7 0 14 -262144 -1 0; #X obj 7 100 cnv 15 50 12 empty empty 1024 0 7 0 14 -262144 -1 0; #X obj 7 115 cnv 15 50 12 empty empty 1280 0 7 0 14 -262144 -1 0; #X obj 7 129 cnv 15 50 12 empty empty 1400 0 7 0 14 -262144 -1 0; #X obj 7 144 cnv 15 50 12 empty empty 1680 0 7 0 14 -262144 -1 0; #X obj 7 159 cnv 15 50 12 empty empty 1920 0 7 0 14 -262144 -1 0; #X obj 126 49 cnv 15 50 12 empty empty right/left 0 7 0 14 -262144 -1 0; #X obj 7 53 cnv 15 50 12 empty empty 320 0 7 0 14 -262144 -1 0; #X obj 7 70 cnv 15 50 12 empty empty 640 0 7 0 14 -262144 -1 0; #X obj 7 35 cnv 15 50 12 empty empty window 0 7 0 14 -262144 -1 0; #X obj 133 66 cnv 15 50 12 empty empty offset 0 7 0 14 -262144 -1 0 ; #X obj 2 1 inlet; #X obj 168 121 tgl 50 0 start_stop start_stop_ext empty 0 -6 0 8 -258699 -1 -1 0 1; #X obj 35 2 s create_2; #X obj 8 20 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 27 28 cnv 5 100 10 empty empty 2eme_X 0 0 0 14 -262144 -66577 0; #X obj 195 4 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X msg 238 18 lighting $1; #X obj 195 21 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X msg 244 53 border $1; #X obj 144 5 cnv 15 50 12 empty empty light 0 7 0 14 -262144 -1 0; #X obj 134 20 cnv 15 50 12 empty empty border 0 7 0 14 -262144 -1 0 ; #X connect 1 0 0 1; #X connect 2 0 0 2; #X connect 3 0 0 3; #X connect 22 0 0 0; #X connect 25 0 24 0; #X connect 27 0 28 0; #X connect 28 0 0 0; #X connect 29 0 30 0; #X connect 30 0 0 0; #X coords 0 0 1 1 230 180 1 0 0;
Quoting james tittle tigital@mac.com: 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...
That would be very nice to have for installation work and a single display. I tried the 'kiosk' API stuff in GEM but of course it does nothing without window focus.
...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)?
'secondscreen' is defunct.
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-
B. Bogart -
chris clepper -
cyrille henry -
Hans-Christoph Steiner -
james tittle -
zmoelnig＠iem.at