More > JRiver Media Center 28 for Windows
FEATURE REQUEST: Tag Window Menu additional options
HPBEME:
--- Quote from: Matt on May 30, 2022, 02:00:41 pm ---I don't feel that strongly on this. I'm just saying it is working as intended. Another approach would be for big edits to always eat the wheel even if there's nothing to scroll.
--- End quote ---
Well by all means then... let's have big edits "eat the wheel" ;D
I am not clear what the advantage is as currently configured… You can already easily close the large edit window by simply clicking on the label again (which is how I've always done it). What makes it bizarre is that in no other software I have used, does scrolling the wheel or clicking on the scroll bar result in something getting closed.
Given its unexpected nature and ease with which you can accidentally invoke it, to me it's a no-brainer… "eat the wheel" ;D
markf2748:
--- Quote from: Matt on May 30, 2022, 02:17:59 pm ---The scrollbar only appears when necessary. But that's the problem.
It doesn't appear for some fields so scrolling goes to the outer container.
--- End quote ---
I see, thanks for the clarification.
--- Quote from: Matt on May 30, 2022, 02:17:59 pm ---We could make mouse wheel always eaten by the window even if it doesn't have a scrollbar. Like I said, I don't feel strongly.
--- End quote ---
That's ok with me, as long as the inner scrollbar follows the common convention (as it does now): only appear when there is something to be scrolled.
On the other hand, re current behavior with an under-filled full-height text box (no inner scrollbar), I am willing to be careful about not scrolling until closing the overlaid text box. In this approach, I view the closing by scrolling as a clever, extremely fast shortcut that will be used a lot. Once understood, people may quickly adapt. Time will tell, but I might prefer it.
MC 29.0.55 Win 10/11 (64-bit)
HPBEME:
--- Quote from: markf2748 on May 30, 2022, 02:30:59 pm ---I am willing to be careful about not scrolling until closing the overlaid text box. In this approach, I view the closing by scrolling as a clever, extremely fast shortcut that will be used a lot. Once understood, I predict people will quickly adapt.
--- End quote ---
Well I'm glad you're willing, but that misses (part of) the point I was making. Using a hyper scroll wheel mouse is supremely beneficial in a media program where your regularly scrolling very long lists. But now, even the tiniest bump of the scroll wheel will close the edit window as it is now configured.
So it is not simply a matter of "adapting" - the sensitivity of the hardware is also a factor, and in my testing it is extremely annoying.
It is hardly a burden to simply click on label to close the tag edit window like we've always done prior to this change. But having the window close unexpectedly is a huge deal, and your assumption that people will quickly adapt to this behavior, one that does not exist in any other software mind you, I think is simply wrong.
So I guess I vigorously disagree with you on this point, and I implore Matt to "Eat the wheel… Eat it!"
Matt:
I'm going to try making inner controls that don't need the mouse wheel eat the wheel anyway. That way scrolling will not switch fields.
Thanks for all the help.
Navigation
[0] Message Index
[*] Previous page
Go to full version