Planoform, the thing is, sometimes you want to actually prevent someone from escaping the app until a certain time... or even create irritating apps :)
The idea of it being a default connection is interesting since it's pretty standard convention as far as apps go. I'm not sure if that would be a good default to have in place all of the time?
Make sure that you are aware of the Quartz Builder template (are you?). The shift to Snow Leopard made the fact that there is a template that you can build onto, which allows you many more options in your app. Choosing to install it when you start up Quartz Builder for the first time will deposit in your Templates folder in the Developer folder. (/Developer/Library/Quartz Composer/Templates)
Open that template up, and basically, cut and past your qtz on top of it, or build directly on top of it.
Checkout options for window levels, ignore mouse events, etc., and please post back with comments or any questions.
This was the original Quartz Builder discussion thread from right after release, and there is probably some pretty valuable run downs on it. Keep in mind this was all in the context of Leopard, though much of it should apply to current day (except for basically some mouse forwarding issues in SL, and some refinements with Quartz Builder). Now, Opacity is default, a clear isn't needed (I don't think), and there are some more advanced options.
The other thing that is different is that the Quartz Builder template isn't going to show up in the opening "drop down" for Quartz Composer, where you can choose protocol templates, due to a change in the Quartz Composer app that makes the start up non-dynamic (though it is based on a mind blowing qtz file, which I am in total nerd lust over). Simply making something a "quartz builder protocol" via the Editor "Edit Protocol Conformance" will not give you all of the Template options. That said... for a really basic functioning app, you can just drop a qtz right into Quartz Builder, and it should build a functioning app.
gtoledo3 wrote: Planoform, the thing is, sometimes you want to actually prevent someone from escaping the app until a certain time... or even create irritating apps :)
He states the request as an "option" -- i.e., a checkbox you can select to have the Runner environment handle app termination for you, so you don't have to do it in-composition.
I think that's a pretty reasonable request (and would definitely improve performance, since you'd have fewer patches overall, and fewer patches that are idling most of the time).
Chris...remember (well, I'm sure you obviously do) that you don't even have to have more patches to quit the app- right now Command+Q does quit the app, and I should have added that in my original post (and it's noted by hovering over the "closable" option in Advanced settings). Not saying that esc couldn't too... it does make good sense.
So, you don't need to have patches idling to achieve that (that is a good argument for key control to exit... less patches is always better), but it already exists built in, and you don't even have to think about setting it up, as long as the app is closable. Adding escape as a possible way to do it would be pretty intuitive as well though, I agree.
i think the paradigm is used a lot, mainly with the flash movies etc.. on you tubes and stuff so from a users standpoint it is something we are all familiar with. so if someone using an app that needs to get out will automatically try i know thats what i did on my first full screen QB build.
i would hope the terminate app function will still be available as i think it will but we need to remember that the keyboard events seem to only be working in a focused context and not a global context. i see some cool things that could be done with keys and mouses in a global context, as far as desktop applications are concerned.
My opinion is that having Esc is an ill considered default, since it's not in accordance with the way the OS X works. Hitting Esc doesn't exit apps, Command+Q does, and that's the current way that it works. It doesn't seem like it should be shifted to a default that isn't in line with standards just because one person asked, and it can be done (cough cough/ gentle poke).
Esc fits into the paradigm of a Viewer screen... but these are apps. I guess it's not a bad option to have via Advanced Settings, but it shouldn't be checked by default.
actually george hitting escape doesn't get you out of the QC viewer. trust me flash and quicktime have conditioned me to hitting esc but it does no good in QC
You're right, it only pops the Viewer down from Fullscreen. You're strengthening my thought that this is an interesting request. It could be applied in many scenarios that don't fit in with typical guidelines. The irony of the fact that I'm saying this in a discussion about QB isn't lost on me either, as many whacky options are available :)
You have me thinking... even in Quicktime, it doesn't stop the Quicktime viewer from running, it's only a minimizes from Fullscreen, but keeps Quicktime running. (I'm not 100% sure about Flash, but I think it doesn't quit in that case either).
The only scenario that Esc to quit an app actually fits in with, that I'm aware of, is the Front Row paradigm, where hitting Esc actually does quit the app. Fullscreen fade in stuff exits by Esc, other stuff doesn't, in OS X.
I'm trying to remember if hitting Esc does exit any other apps, ever (maybe in Windows)? I don't have all of my X11 stuff running in SL so I can't check it out quickly. I seem to remember having an X11 based video game that did that.
Is there still a template floating around? I'm wondering if it would allow me to hide the mouse while in fullscreen. If there is a template where would I find it? As for the QC template chooser being non-dynamic def file a bug.
planoform wrote: Is there still a template floating around? I'm wondering if it would allow me to hide the mouse while in fullscreen. If there is a template where would I find it?
Yes, when you run QuartzBuilder, it automatically installs the template and protocol plugin. The path to the template is /Developer/Library/Quartz Composer/Templates/QuartzBuilder.qtz
planoform wrote: As for the QC template chooser being non-dynamic def file a bug.
you can set any key you want to get out of the application all ready or make a button or set the application to quit after x time. here press q!
Right on Dust!
Planoform, the thing is, sometimes you want to actually prevent someone from escaping the app until a certain time... or even create irritating apps :)
The idea of it being a default connection is interesting since it's pretty standard convention as far as apps go. I'm not sure if that would be a good default to have in place all of the time?
Make sure that you are aware of the Quartz Builder template (are you?). The shift to Snow Leopard made the fact that there is a template that you can build onto, which allows you many more options in your app. Choosing to install it when you start up Quartz Builder for the first time will deposit in your Templates folder in the Developer folder. (/Developer/Library/Quartz Composer/Templates)
Open that template up, and basically, cut and past your qtz on top of it, or build directly on top of it.
Checkout options for window levels, ignore mouse events, etc., and please post back with comments or any questions.
This was the original Quartz Builder discussion thread from right after release, and there is probably some pretty valuable run downs on it. Keep in mind this was all in the context of Leopard, though much of it should apply to current day (except for basically some mouse forwarding issues in SL, and some refinements with Quartz Builder). Now, Opacity is default, a clear isn't needed (I don't think), and there are some more advanced options.
The other thing that is different is that the Quartz Builder template isn't going to show up in the opening "drop down" for Quartz Composer, where you can choose protocol templates, due to a change in the Quartz Composer app that makes the start up non-dynamic (though it is based on a mind blowing qtz file, which I am in total nerd lust over). Simply making something a "quartz builder protocol" via the Editor "Edit Protocol Conformance" will not give you all of the Template options. That said... for a really basic functioning app, you can just drop a qtz right into Quartz Builder, and it should build a functioning app.
http://kineme.net/Release/Production/QuartzBuilder
He states the request as an "option" -- i.e., a checkbox you can select to have the Runner environment handle app termination for you, so you don't have to do it in-composition.
I think that's a pretty reasonable request (and would definitely improve performance, since you'd have fewer patches overall, and fewer patches that are idling most of the time).
Chris...remember (well, I'm sure you obviously do) that you don't even have to have more patches to quit the app- right now Command+Q does quit the app, and I should have added that in my original post (and it's noted by hovering over the "closable" option in Advanced settings). Not saying that esc couldn't too... it does make good sense.
So, you don't need to have patches idling to achieve that (that is a good argument for key control to exit... less patches is always better), but it already exists built in, and you don't even have to think about setting it up, as long as the app is closable. Adding escape as a possible way to do it would be pretty intuitive as well though, I agree.
I added this feature this morning (just a few lines of code in the builder and the runner environment -- pretty easy). So this will be in version 1.2.
That sounds like that's going to work well hand in hand with the fade in/fade out for people. Ultra Front Row style :)
If something is hooked to App terminate using the Template now, will this just work "in addition", or will it over-ride?
i think the paradigm is used a lot, mainly with the flash movies etc.. on you tubes and stuff so from a users standpoint it is something we are all familiar with. so if someone using an app that needs to get out will automatically try i know thats what i did on my first full screen QB build.
i would hope the terminate app function will still be available as i think it will but we need to remember that the keyboard events seem to only be working in a focused context and not a global context. i see some cool things that could be done with keys and mouses in a global context, as far as desktop applications are concerned.
My opinion is that having Esc is an ill considered default, since it's not in accordance with the way the OS X works. Hitting Esc doesn't exit apps, Command+Q does, and that's the current way that it works. It doesn't seem like it should be shifted to a default that isn't in line with standards just because one person asked, and it can be done (cough cough/ gentle poke).
Esc fits into the paradigm of a Viewer screen... but these are apps. I guess it's not a bad option to have via Advanced Settings, but it shouldn't be checked by default.
actually george hitting escape doesn't get you out of the QC viewer. trust me flash and quicktime have conditioned me to hitting esc but it does no good in QC
You're right, it only pops the Viewer down from Fullscreen. You're strengthening my thought that this is an interesting request. It could be applied in many scenarios that don't fit in with typical guidelines. The irony of the fact that I'm saying this in a discussion about QB isn't lost on me either, as many whacky options are available :)
You have me thinking... even in Quicktime, it doesn't stop the Quicktime viewer from running, it's only a minimizes from Fullscreen, but keeps Quicktime running. (I'm not 100% sure about Flash, but I think it doesn't quit in that case either).
The only scenario that Esc to quit an app actually fits in with, that I'm aware of, is the Front Row paradigm, where hitting Esc actually does quit the app. Fullscreen fade in stuff exits by Esc, other stuff doesn't, in OS X.
I'm trying to remember if hitting Esc does exit any other apps, ever (maybe in Windows)? I don't have all of my X11 stuff running in SL so I can't check it out quickly. I seem to remember having an X11 based video game that did that.
Yes, we agree --- this option will be available, but disabled by default.
Is there still a template floating around? I'm wondering if it would allow me to hide the mouse while in fullscreen. If there is a template where would I find it? As for the QC template chooser being non-dynamic def file a bug.
Yes, when you run QuartzBuilder, it automatically installs the template and protocol plugin. The path to the template is
/Developer/Library/Quartz Composer/Templates/QuartzBuilder.qtzGood idea. I just filed radr://7670590.