Many of the UI widgets only function once the mouse button has been released, rather than on the initial click of the button.
For example, clicking play/stop, and the menu (file, edit, view, help), or turning tracks on/off, or clicking the slider to a new position, or switching between the Pattern Editor and the Mixer etc. etc. It’s particularly noticable with the menus since usual Windows menus function on mouseclick-down.
Others widgets are actually fine - entering music in the editor, adding/removing a sequence, changing volume sliders, selecting a range of notes, etc.
One may notice that the latter examples feel much more ‘snappy’, and generally nicer to work with. Obviously the latency makes all the difference, so I propose all widgets switch to the more standard ‘press-down’ mechanism for improved responsiveness. It should be quick to change. What do others think?
Yes you’re right of course. It’s still a nuisance though - maybe there’s some way to disable it in Windows?
I wonder why though. The thing is if you’re gonna hesitate about clicking (which is maybe 10% of the time?), then you could simply click 0.2s later (covering for the fractions of a second between mouse-up/down) which would give you the same time gap to correct your mistake. In any case I rarely make a mistake, and when I do I don’t usually have enough reaction time in between the mouse down and mouse up to realise my mistake. In the very rare times I do, then there’s always the ‘undo’.
Also, allowing immediate action on mouse-button-down means you can move the mouse away immediately to do something else, and you can be certain the action has been carried through. Sometimes, I find that I’ve clicked, and moved the mouse away to soon, and find it didn’t really click at all.
Overall, things are more snappy/responsive, and stuff can be done faster. Renoise has the advantage of using its own custom GUI, so in theory it can be fixed…
Bah, I bet I’m the only one who cares about something this seemingly ‘trivial’ Next we’ll have clippy popping up and asking “you clicked a button, are you sure wanted to do this?”.
Whether or not I would personally isn’t the question. There’s an entire userbase to consider. If you make changes in UI like this you have to be aware that you could be pissing off a LOT of users who are used to the way things were. Not everyone’s as perfect as you… cough … most people have a tendency to sometimes accidentally click where they didn’t want to, and actually use the function of being able to drag out of the button before releasing.
To be honest, apart from said responsiveness (which may be felt more on a subconscious level where people feel it’s quicker without really knowing why), I doubt anyone would even notice. And I still reckon the error rate of wrong button clicking happens in 99.8% of cases regardless, since the ‘drag out’ technique you mentioned (which I have done myself on occasion) has such a small ‘time window’.
Yes, as said earlier, the pattern adding/removing button responds on button-down. Be nice for more buttons to be like that, since the convention isn’t necessarily best (though maybe I haven’t thought of something).
In any case the choice would be great as BYTE-Smasher said.
If everyone thinks for everyone else not a single decision can be made that is satisfactory for anyone. Let people speak for themselves FFS. Or are you just covering your personal views by speaking them out as the best for the community?
I think this is essential for Windows-style dropdown menus that can be opened with mouseDown and then a menu item can be selected with mouseUp. For the panels I dunno, but I wouldn’t mind for sure. Maybe to view the panel on mouseDown and lock the view on mouseUp, then I could f.ex. check the mixer by pressing mixer tab and then drag back to pattern editor, release the mouse button and keep on editing. Also keyboard focus should follow on mouseUp, and if cursor would be dragged outside of panel button before mouse button release then currently viewed tab should stay and gain focus, unless of course cursor would be dragged back to panel buttons.
No you’re right… I’m covering my personal views on taking away functionality, and how it affects end users. I’m a programmer by trade dude… I’ve seen how making seemingly harmless UI changes like this can affect end users. I’ve had to answer the big question before
But why did you take away that feature?!!?!
because we didn’t think you actually used it?
WELL THANKS FOR THINKING FOR US MR ASSHOLE DEVELOPER epic facepalm
That said… Anyone look at the new Facebook layout? Don’t you just love how they’ve taken away the news feed preferences and replaced it with a stupid filter that has half the functionality but is slightly quicker to use? … yah… I thought so.
Why the fuck do I even bother? shoots himself in the head
To clarify, I meant that you should not second-guess what other people want, be it changing or conserving things. But this might come too late, you are already dead, aren’t you, mr. Bite-Smasher?
BYTE-Smasher’s got a point - there may be more people who hold the mouse button down before releasing than I realised. In which case, the option would be good as said before (and then slowly, the developers can replace each button, one by one, with the onMouseDown way ).
That’s the thing though, I’m assuming most people count it as a single click and immediately release the button. They don’t (usually) have time in that small time frame (0.2s say) to reverse their decision. The exceptions would be for dragging (sliders etc.) or for the (probably very few?) people who habitually press buttons, and hold it before releasing. In which case I would say to those it’s just a (non-constructive) habit which can be broken easily.
In all fairness, Windows buttons tend to use the onMouseUp way. Still, it’s not quite as good even if I do say so myself.
Next we’ll have clippy popping up and asking “you clicked a button, are you sure wanted to do this?”.
… it has an infinite time window. As long as you keep clicked, you can get out of it.
