GUI conventions: Knob

jorge · 15 Jun 2005

What about having the cursor disappear completely as it is already possible?

Nu Audio Science · 15 Jun 2005

I think the capabilty was added a while back to customise the cursor ?

The cursor staying centered thing has been asked for a lot aswell C, I'm pretty sure Malc said it would happen 😉

I'm busy at the mo but i will try and find the threads and link em here for you later.

skOre · 15 Jun 2005

There was somewhere a thread about custom cursors being about to be implemented, right?

Guess a Hand would be right, yes. The dot is more or less a non-statement. Suitable for X/Y-controllers however - the dot does not seem to be bound to a direction.

I think SM should ship a couple (by couple I mean at least twenty) of cursors, so that a programmer could chose between a number of SM-"related" cursors, so that there wouldn't be "oh, that cursor, must be SM-created"-reactions. Maybe it could be a good insider-thing to tell a SM synth by the cursor... but not at first sight 😉

cbit · 15 Jun 2005

jorge wrote: What about having the cursor disappear completely as it is already possible?

thats even better.. i don't have any vsts infront of me at the moment to check, but a disappearing cursor is a common approach isn't it? (i thought so..)

Nu Audio Science · 15 Jun 2005

yeah it seems like the dissapear is the most common approach 🙂

malc · 15 Jun 2005

I think this all sounds good to me.

Custom cursors will be possible but perhaps we should change our default too.

You can already hide the cursor using the Show Cursor component although this needs some more work. Would be easy to extend it to freeze the cursor while turning a knob.

cbit · 15 Jun 2005

that would be great!

GaryG · 16 Jun 2005

I just tried adding a Show Cursor element to a simple knob schematic; cursor certainly disappeared, I just couldn't get it back again... 🙂 Had to close SM completely and go back in for it to re-appear.

Still needs some work? What would be the 'correct' way of hiding the cursor? Mouse down event, neg'ed then into the Show Cursor input or something?

malc · 16 Jun 2005

Sorry about that GaryG, it is a little dangerous and that is indeed one of the things that needs more work 😉.

That said if we allow the flexibility to control such things then you do have to be careful how you use them. Please don't take that the wrong way, I'm not blaming you, it's just that with low-level functionality comes the risk of trouble if you accidentally get it wrong 🙂. Anyway, I'd like to make it a bit safer.

For an example of how to use it, see the example here: Hide Cursor

Just copy the Hide Cursor module from the schematic I posted there.

infuzion · 17 Jun 2005

malc wrote: Sorry about that GaryG, it is a little dangerous and that is indeed one of the things that needs more work 😉. ... Hide Cursor Just copy the Hide Cursor module from the schematic I posted there.

Yea, you need a mechanisim to turn on the cursor again after you turn it off. 🙂

GaryG · 17 Jun 2005

malc wrote: That said if we allow the flexibility to control such things then you do have to be careful how you use them.

oh quite, with great power comes great responsibility. 🙂

after posting I saw that topic you referred too, using it that way works fine so obviously my dodgy 'coding' yet again... 🙂

on a tangent, i assume you'd obviously have to have that hide cursor module in each knob, slider you use; will it have a significant cpu hit, assuming the code is duplicated? It hasn't been a problem but i do find myself duplicating large chunks of code sometimes and have wondered if it's realy efficient. Though I guess anything using a visual metaphor will look 'bloated', a whole network of elements could boil down to just a couple of lines of assembler...

malc · 17 Jun 2005

Hi GaryG,

Yeah, you would have to have the module in each knob. This won't affect cpu adversely at all. What it does affect are memory useage and file size and even though these are not bad at the moment they can still be improved.

GaryG · 21 Jun 2005

back to hiding cursors... 🙂

I figured out my mistake, simply releasing the mouse outside the mouse area. I can always get the cursor back by clicking (blindly 🙂) back on the knob.

So... can't a mouse_up be somehow unbound by an area? So you click on a knob, cursor is hidden, you adjust the value (straying from the area while doing so) then release the button and a mouse_up is generated even though it's outside the knobs area? I understand this would conflict with other modules that may use the mouse_up for other purposes but if the behaviour was made an option then you could at least use it when you were certain you wouldn't be doing any clever stuff...

am I being too simplistic?

Incidentally: I get the impression SM is a european creation? So why the daft spelling of 'center' on the text format fields etc.? 😉

infuzion · 21 Jun 2005

This works for me: malc wrote: For an example of how to use it, see the example here: Hide Cursor

Just copy the Hide Cursor module from the schematic I posted there.

The actual cursor postion won't move if you make the Hold True. You have to have some way of making the Show boolian turn true again, like LUp or a Control key, or maybe a timer.

malc · 21 Jun 2005

Hi GaryG,

GaryG wrote: So... can't a mouse_up be somehow unbound by an area? So you click on a knob, cursor is hidden, you adjust the value (straying from the area while doing so) then release the button and a mouse_up is generated even though it's outside the knobs area?

It can indeed. This is how the Drag Accumulate components work. As you've noticed, mouse messages are sent to the mouse area that is under the mouse pointer. We could add a component (or components) that would allow you to send all messages to a particular mouse area regardless of whether the pointer is over that area. This is known as capturing the mouse. You would then release the mouse when you are finished.

Of course if we did this then you would have to be careful to release the mouse otherwise it would stay captured. Another added responsibility, but perhaps worth it if you get flexibility in return 🙂

Best to use the drag accumulate components to do this for now. At some point I'm sure we'll look at giving you control over mouse capture.

GaryG wrote: Incidentally: I get the impression SM is a european creation? So why the daft spelling of 'center' on the text format fields etc.?

🙂 - yeah, it is a European creation. You can use 'centre' if you want as this should work as well. I think we used 'center' in the documentation and pop-up help because we were used to it from coding - just force of habit.

GaryG · 21 Jun 2005

Thanks Malc,

I think I've got my head around this now (bear in mind I'm not a Windows programmer so have never had to deal with things like mouse messages before).

However, I still can't hide the cursor properly... 🙂 your example has the same problem as my attempts; the cursor stays hidden if you release the mouse away from the control.

Please don't waste any time on my part on this, I'm moving on to other stuff, will re-visit this topic later (hardly a 'core' issue... 🙂)

I'm still having way too much fun with SM, I find myself approaching some tasks I set myself almost as logic puzzles, coding way into the night... I guess it's time to early adopt. 🙂

Gary.

Tom7777 · 22 Jun 2005

However, I still can't hide the cursor properly... 🙂 your example has the same problem as my attempts; the cursor stays hidden if you release the mouse away from the control.

2 workarounds for this although not the best method is to

1 - resize the area to slightly larger than the actuall panel itself.

2 - make the Mouse Up event seperate areas and use the area convert with floats that are much bigger than the actual area and then connect this so this way its very unlikely that you can not release the mouse correctly and it will work every time.

I always find workarounds 🙂

GaryG · 22 Jun 2005

life is a workaround sometimes... 🙂

Cheers Tom, much appreciated.

.g

Tom7777 · 22 Jun 2005

No problem 🙂

malc · 22 Jun 2005

Actually, I think that example worked in a previous release but it shouldn't have. I've changed it a bit now so if you follow the same link you'll see the changes I've made. The most important change is that instead of re-showing the cursor on mouse up, it does it when the drag operation is complete.

If you download this again or make the necessary changes to your local copy you should find that it works nicely.

It's still not perfect though. One issue is that the movement of the knob is related to the mouse position. So if you have a small scale for fine tuning, even though the cursor is hidden, behind the scenes it might reach the top of the screen and the knob will stop moving even though you keep moving your mouse.

This was something that Tom alerted me to, a smallish issue but nevertheless one that needs to be dealt with (it's on the list Tom 🙂)

infuzion · 22 Jun 2005

malc wrote: I've changed it a bit now so if you follow the same link you'll see the changes I've made. The most important change is that instead of re-showing the cursor on mouse up, it does it when the drag operation is complete.

If you want smaller code, you can remove the MouseLDown; just connect the HideCursor trigger to DragY's BeforeChange output. Seems that BeforeChange activates on focus:

BTW; it's kinda dangerous connecting things to that HideCursor; your cursor might disapear 🙂