Button states in QC app — Best approach

usefuldesign.au's picture

I have an app i am building in QC that will have >20 buttons that need to be 'clickable'. They will mostly have on and off states showing an LED light or dark and a bit of glow around the LED on the panel artwork I guess.

I'm wondering if the best way to do the Artwork is to have two full screen images of the Front Panel as TIFF or PDF artwork — with all buttons in OFF state and another with all buttons (LEDs) in the ON state. Then use an Core Image Accumulator patch to mask/unmask the ON image in regions where particular buttons are ON.

The other way I'm considering is to maybe draw a single button and surround in an iterator and use a (x,y) co-ordinates structure to place all the instances of the ON / OFF image on the screen. Probably do the hit testing inside the iterator too in that case.

Are there any tried and true methodologies in QC?

I've seen the masking approach used in Mac app resources in the past I seem to remember.

Obviously Flash/HTML+JS approaches don't really apply with QC lacking a DOM but maybe there's some wisdom to be gleaned there too?

.lov.'s picture
Re: Button states in QC app — Best approach

Why don't use just Interaction with MouseDown?

.lov.'s picture
Re: Button states in QC app — Best approach

Ahh, bad. Why don't use Snow Leopard? :) I think with Leopard this will be a pain in the ass.

usefuldesign.au's picture
Re: Button states in QC app — Best approach

1 im on PPC and want to do it now 2 I want this to be usable with any version of QC.

gtoledo3's picture
Re: Button states in QC app — Best approach

Also, I put together a "QCButton" that has a few different modes - it can act as a button, a toggle, or a key. It's in the widget at my site. This was advantageous for me, as I wanted to be able to have a the different modes (eg- something that emulates a "button" on a NES should activate when you hit it, not when you release it, like a in OS X. As long as you have that going, it makes sense to go ahead and throw in the toggle mode.

I think that the main question is if each button needs to make something "do something" or if it's purely a color/image change.

You should definitely look into the stock Hit Test patch if image masking is beneficial to you, because there IS a built in mask - anything that's alpha won't cause the hit test to register, which is handy. I found that my thought that it wasn't acting properly was because of my own improper setup of it, and another plugin that was corrupting GL state. It also works in iterators and has built in Z.

PreviewAttachmentSize
QCButtonPatch.zip41.24 KB

usefuldesign.au's picture
Re: Button states in QC app — Best approach

Thanks matt, I like how they are click-able in the OS X preview in column view!

You could have them link to an applescript or something.

Just looking now, I'm surprised by the amount of code in these guys. Being able to set button rotation is a nice touch.

dust's picture
Re: Button states in QC app — Best approach

there are a lot of ways to go about doing this. applying the glow or gloom etc.. on the hit can all certainly be done in qc. i think a photoshop approach might a little less messy. using a combination of boolean, multi-plexors, conditionals, logic, pulses and the private hit tester will be the tools of choice in qc. making lets say a single button macro and then iterating the macro to place the buttons would be my approach. sometimes that gets a bit tricky and easier just manually place a few buttons.

i found things like drop down menus on a website or something is easily achieved by changing lets say the height of the hit test once the initial button as hit so that when lets say the vertical drop down appears you can select those buttons that can trigger another sub button menu and so on. i don't know if that is clear or not, but lets say you have a button on the screen that pops down another button you need the intial hit to pull the menu down but you don't want the menu to pulled down if you roll over the zone where the hidden button is i guess so you need to dynamically change your hit zone for button based on its over state so that button 2 appears.

if you do not do this every time you go to select button two you roll out of the button ones zone making button two disappear before you can push it so by expanding the hit zone of button one to be that of button one and two only when button one is hit makes it possible to do the drop down and sub menus.

everything else is esthetics as per to glow or to not glow. i know your on a ppc so chris's normal map patch probably will not work for you but by changing the position of the lighting in the glsl patch gives you a good depth cue as if a button is pressed or not.

so im sure you could come up with some sort of similar approach with glows glooms and a lighting patch to give users a clear visual clue. which can be just as easily achieved with a few different photoshop states but if you keep it all in qc things like changing a name of the button wouldn't require opening photoshop file etc..

here is a qc4 toggle macro that i think will you will find helpful. it should run in qc3 as it is a multiplexor and a counter.

PreviewAttachmentSize
Toggle.qtz2.71 KB

usefuldesign.au's picture
Re: Button states in QC app — Best approach

Thanks George

I'm having another look at your button, it seems a little snappier than the ones on QCompostions, with >20 buttons I don't want too much memory overhead or fps suck-per-button that's for sure.

The buttons do something, sometimes they toggle, others hold for a few seconds waiting for a second button press (2 digit number entry) then default to passive state at time out or when second button is in-fact pressed which results in a state change for the comp.

Much of the app logic it is already done, with this being a GUI overlay to boolean and number input splitters that currently do the job. I generally just need pulses out but the buttons need to be told when to go 'OFF' too.

usefuldesign.au's picture
Re: Button states in QC app — Best approach

Thanks for the input, Dust. I'm going the 3D model –> Photoshop for lighting–> Two image states for buttons in QC route, I think.

Just a question of whether I attempt this as one big 'sheet' of buttons and hit-test for them all at once in JS or make one button then repeat the macro 20+ times and have each one do it's own hit testing.

dust's picture
Re: Button states in QC app — Best approach

both have there advantages and disadvantages. the lightest possible approach would actually be to use a texture atlas in PVR format. by using a sheet or texture atlas in a compressed image format has many advantages. which include only having to load up one image into memory. by formatting the atlas texture the gpu can rasterize the image faster once it goes down the gl pipeline because it is based on a per pixel, per vertex calculation. so by using compression those pixel arrays can be drawn faster.

the whole process is programmatically much more complex in 3d than just testing an image rect in 2d. this requires ray casting two dimensional coordinates into the 3d world to test for an hit. i found similarly to the ray cast method firing an invisible object into your 3d world from the mouse coordinates and then tracking the distance between them to calculate for a hit simpler to comprehend than ray casting. also using a texture sheet will let you programmatically swap button textures around and probably the preferred method for a mobile device.

on your g5 i don't see why 20 different photoshop images should be an issue, i mean using one image or 20 images the same size as one image shouldn't make a huge difference on your machine.