Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[markf2748]

(deleted by markf2748)

[HPBEME]

but maybe it provides a hint about the current issue of the large edit window closing.

I think what Matt described in his last post indicates that this is the intended behavior.  I erroneously interpreted the behavior as inconsistent because the particular artists I had chosen to do my initial testing on had biographies that filled the edit window.

That said, it is not consistent with how those same fields work in the basic tag window - the amount of text shown does not change how scrolling interacts with the large text edit window. So in that sense, it is not consistent, and for me personally, I don't like it because I now find myself accidentally closing the edit window frequently.

I imagine I will eventually get used to making sure I don't scroll when I'm in a large edit field, but then again, I'm not sure. The "freewheeling" hyperscroll wheel on my mouse makes it very easy to accidentally scroll, which will then accidentally close that window.  I will be curious if others also find the auto-closing aspect irritating, or if I will be the only one who cares.

So there you go Matt… All this proves once again that no good deed goes unpunished!  In any event, I truly do appreciate your spending the holiday looking at this, making changes, and conversing on this thread.

[Matt]

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.

[markf2748]

I would welcome a tweak that has no scrollbar as long as text under-fills the window height.

As soon as you hit a carriage return that overfills the height, scroll bar appears.  I think that is quite common, even expected, in text editing windows.

[Matt]

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.

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.

[HPBEME]

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.

Well by all means then... let's have big edits "eat the wheel" 
 
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" 

[markf2748]

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.

I see, thanks for the clarification.

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.

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]

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.

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.