View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000099||OpenMPT||Feature Request||public||2011-04-01 18:12||2012-10-12 14:39|
|Reporter||harbinger||Assigned To||Saga Musix|
|Target Version||OpenMPT 1.20.04.00 (upgrade first)||Fixed in Version||OpenMPT 1.20.04.00 (upgrade first)|
|Summary||0000099: Mousewheel number editing for more text boxes|
The mousewheel can be used to n-crement the values in the Crossfade dialog and the new Instrument Ramp field, which make it more convenient for mouse-only entry. I've also discovered the mousewheel will move sliders (and change their values) if you click on them first with either the left or middle mouse button, and that most comboboxes will scroll thru the list if you do the same (the noticeable exception being the Pattern Editor's instrument list, as mentioned in another bug report)
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
Seems like I've found out what causes the different mousewheel behaviour between various controls... This will be unified in the next release.
Revision 1365 should improve this; All spin boxes that I could find should accept mouse wheel scrolling now.
Excellent! One step closer to complete mouse-driven composition! The mousewheel does indeed work on all spinner text fields in every tab, and (almost) all drop down comboboxes when they have focus of course.
Furthermore, any slider element (like the Global Volume slider) if it has focus will move according to the mousewheel. If you mousewheel the entry in the spinner text box instead, the slider will also instantly update.
Anomaly, may need to be changed: when mousewheeling to an unused plugin slot in the Instruments page, the Autoselect Plugin feature kicks in. May want to opt out with mousewheel selection or filter the input if possible to only activate when empty slot is singularly chosen by a mouseclick.
Mousewheeling in dialogs:
While i don't really like the Transpose contextual menu compromise (i still think +/-4 and +/-7 are common enough to warrant their entry into the list), at least the Transpose dialog uses the mousewheel to scroll quickly thru the values to get what i need nearly as quickly as possible.
With this new capability, perhaps we can have a preference to opt out of spin arrows (those elements are simply not drawn).
<blockquote>(If you're keeping track, the Instrument field on the Patterns Page and the Zoom dropdown stop moving after the first new list item. I also noticed this is true if the "little" sliders -- like the Res value in the Instruments page -- are mousewheeled when they gain focus.)</blockquote>
While there is definitely room for improvements, this is not related to the original issue.
<blockquote>Anomaly, may need to be changed: when mousewheeling to an unused plugin slot in the Instruments page, the Autoselect Plugin feature kicks in. May want to opt out with mousewheel selection or filter the input if possible to only activate when empty slot is singularly chosen by a mouseclick.</blockquote>
Cannot be fixed (at least for now), since the same code is always used when a new plugin slot is chosen, no matter if via mouse click, keyboard or wheel.
<blockquote>With this new capability, perhaps we can have a preference to opt out of spin arrows (those elements are simply not drawn). </blockquote>
I know some of the issues were not related directly to the original FR, but i figured i'd put all the testing i did with the mousewheel in one thread, so you/we can refer to this later if needed.
Just mentioning the plus/minus of the mousewheel in the dialogs. My point was not to complain that i couldn't get what i wanted, but to remind users and future devs that the mousewheel in the Transpose dialog makes for a nice consolation prize, as it were. I didn't even pick up that the Transpose dialog had a keyboard shortcut. That's an even better option, considering.
I am always all for reducing unnecessary visual clutter for GUI that a user opts out (leftover trait from my Mac days). Wishful thinking on my part, i admit. I can see by your question, that as the programmer, testing for GUI options and deleting elements on a case-by-case basis better be worth the time it takes to assemble the methods....;D
Overall, good job. And feel free to consider this FR "resolved."
If there's any more dodgyness showing up with the controls, let me know.
|2011-04-01 18:12||harbinger||New Issue|
|2012-09-22 22:39||Saga Musix||Assigned To||=> Saga Musix|
|2012-09-22 22:39||Saga Musix||Status||new => assigned|
|2012-09-22 22:39||Saga Musix||Note Added: 0000892|
|2012-09-22 22:39||Saga Musix||Target Version||=> OpenMPT 1.20.04.00 (upgrade first)|
|2012-09-28 14:10||Saga Musix||Note Added: 0000895|
|2012-09-28 14:10||Saga Musix||Status||assigned => feedback|
|2012-09-28 14:23||Saga Musix||Note Edited: 0000895|
|2012-10-02 20:00||harbinger||Note Added: 0000904|
|2012-10-02 20:00||harbinger||Status||feedback => assigned|
|2012-10-04 18:02||Saga Musix||Note Added: 0000905|
|2012-10-04 18:02||Saga Musix||Status||assigned => feedback|
|2012-10-12 14:37||harbinger||Note Added: 0000906|
|2012-10-12 14:37||harbinger||Status||feedback => assigned|
|2012-10-12 14:39||Saga Musix||Note Added: 0000907|
|2012-10-12 14:39||Saga Musix||Status||assigned => resolved|
|2012-10-12 14:39||Saga Musix||Resolution||open => fixed|
|2012-10-12 14:39||Saga Musix||Fixed in Version||=> OpenMPT 1.20.04.00 (upgrade first)|