TBH, I don't know what should be fixed.
When I use the scroll wheel and the mouse cursor hovers over a piece of grey (background) area of the tag panel, then the whole panel scrolls.
This works until the panel has moved so far under the mouse cursor that the mouse cursor now hovers over a list box. Now the list box scrolls....
I would expect exactly that.
TBH, I don't know what should be fixed.
That is precisely the problem. The list box should not scroll or change content unless you select the "down" arrow at the right end of the list box and deliberately select a different value, or if you intentionally type in different information.
I just checked with the program ACDsee (which means that I checked how the list box behaves there) and there the list box behaves just like in MP3tag: as soon as the list box has the focus, the scroll wheel scrolls through the list entries without the list box being expanded. So it looks to me like some common list box behaviour.
@ohrenkino That's a shame. My tag panel is very long so I use the mouse to scroll a lot when tagging and I keep getting caught out.
If I go into a Microsoft Office app, e.g. Word, and go to Options > Advanced, I get a long dialog with list box fields that exhibit the behaviour that I'd like to see in MP3Tag. When scrolling with the mouse, the dialog scrolls and not the contents of a list box as I start a scroll from it.
I am using a touchpad rather than a mouse, but I think the behaviour is equivalent.
In Office, when you start a two fingered scroll over any part of a scrollable dialog, the whole dialog scrolls, irrespective of whether you start with the cursor over a dropdown box or not, or whether the dropdown box has the focus. If you want to scroll a dropdown contents with the mouse, you click it to give it the focus, then single finger scrolling works (incidentally, the down-arrow gets a border to show it will get the focus if you click when the mouse is over it). Two-finger scrolling still scrolls the containing dialog. To me, this feels intuitive and consistent with what I normally see in the Windows interface.
In MP3Tag tag panel (which seems to be the only scrollable dialog in the app), if you need to make sure the mouse cursor is not over a dropdown if you want to scroll the whole dialog using two fingers. Also you need to click the down-arrow to see the list, whereas in Office, a single finger scroll will make the list appear and scroll to the option you want.
So, there is a precedent, and it is possible. Top of my wish list for MP3Tag usability.
I hope that this was helpful in explaining the issue.
Sorry @d2b about dbd
Thank you for the hint.
I aso scrolled through the long list - and yes: it did modify the contents of a combobox when it got the focus.
I explicidly had to open the combo box.
BUT: when I used the scroll wheel with the open combobox then the contents of the box stayed at the cursor and the other contents of the options window scrolled away ... The context for the opened combobox was completely lost.
I am not sure that I want that behaviour in MP3tag...
Another use case: open a browser on a page that features a map and scroll with the scroll wheel: as soon as the mouse cursor hovers over the map, the map is zoomed, no further scrolling happens for the rest of the page - until you move the mouse cursor to the scroll bars.
So MP3tag is by far not the only program that behaves in the criticized way.
You could place the tag panel at the bottom of MP3Tag. I personally prefer this arrangement. In this way you have more space horizontally for the columns of the column view and also less need to scroll vertically in the tag panel, since a screen is usually wider than it is high, especially with the 16: 9 or 16:10 dimensions that are common today.
I never had the problem that the content of tag-fields got actually deleted because of changing to with the wheel mouse, because I noticed this always before saving.
But what really annoyed me several times was that I accidently changed the directory-field in the tag-panel this way and I had loaded my whole collection, which is very very large.
I takes quite some time to load the files again.
This tag-field and the filter-field are the only ones that have immediate (without saving) consequences after accidently changing them with the wheel-mouse.
In consequence I decided to disable the dircetory-field in my tag-panel.
I don't know how but I think it would be a good idea to change this behaviour.
Yes, that drives me crazy too
Two-fingered scroll for the containing dialog and single-fingered for the combo is a benefit if you randomly access tag panel fields, so you avoid disrupting fields you scroll past. If you also start at the top and work down, there is less of a difference.
I got out a mouse just to ensure two-finger on touchpad is equivalent to the mouse wheel: it is.
In fact the behaviour between Office and MP3Tag is pretty much the same once the combo has the focus, except that Office allows you to scroll away when the mouse is over over the top line of the combo (like cancelling because you haven't changed anything).
@poster's suggestion of putting the tag panel at the bottom is a great work-around - I hadn't realized that was possible or how much better that layout works if you have a large tag panel.
BTW, I am not criticizing MP3Tag, this is just some usability feedback.
First of all, I agree that the behavior is not optimal. I think it's very obvious from @redux's post above. However, I'm not sure about what the optimal behavior might be, because there are always different interests at stake.
Preventing scrolling in this case would disrupt the workflow for all those that simply click into the field and use the scroll wheel (or two-finger scrolling) and expect the field to cycle through the different values. Also, typing is intentionally disabling scrolling to address [F] Tag Panel problems with 'wheel mouse' - #10 by JJ_Johnson.
I don't have Office, so it's a little bit hard to imagine. What do you mean by single finger scrolling? It sounds like this is just moving the mouse cursor, but it's probably a special feature of your touchpad. Do you know the equivalent of that when using the mouse?
One tricky bit is that the Tag Panel background can't get the focus by itself, there is always one field that has the focus. I prefer to keep it that way for all those who are mainly using the keyboard to navigate between the different UI parts.
I've tried finding some good native older Windows examples of panels/dialogs that have select dropdown style widgets, as well as being scrollable, but it seems that in general, Windows avoids having both a scrolling panel AND a select (e.g. going to device manager, getting to the details of a driver, there is a select dropdown that can be scrolled/changed directly with scroll wheel, but the panel itself is sized so that it doesn't need scrolling).
In newer-style panels in Windows 10, it seems that select dropdowns are simply not reacting to scroll wheel at all (for instance looking at the display settings)
For what it's worth, even for web content, where you can have scrolling for the page and then actual
<select> elements, it seems browsers ignore scroll wheel events on the selects.
It may be a case of having to make a choice and suppressing mouse wheel functionality on the selects? having both the panel scrolling and the selects changing on scroll wheel is just the worst of both worlds at the moment / bad user experience.
EDIT: looking a bit closer at the new-style Windows settings panels, it seems (though it's a tiny bit flakey) that it's using some sort of heuristic - if the scrolling with scrollwheel started outside of the select, and is "in progress", the selects don't react at all to the scrollwheel. However, if the mouse started off over one of the selects, then scrollwheel is hijacked to just cycle throught the select options and not to scroll the page (though sometimes, the heuristic appears to flake out on recognising the "in progress" scrolling on occasions) - further edit: ah, it seems that to trigger the second behaviour, the user has had to first click/focus into the select at least once ... only then does it do this heuristic. otherwise, scrollwheel just scrolls the page/panel regardless of where you started the scrollwheel action. anyway, this does appear to be a tough nut to crack / circle to square, as either way a change in behaviour will annoy one group of users that relied on the current one, despite solving the problem for another group of users that were annoyed by the current one. maybe...and i know this is usually the undecided/cowardly way out...make it a setting ?
I've spent the day experimenting and working on that and I think I've found a sensible way of tackling this issue. Thanks @redux and everyone involved for the helpful examples and discussions around that.
This is the new behavior:
Tag Panel scrolling using the scroll wheel doesn't capture the scrolling when hovering over one of the fields. It simply scrolls the Tag Panel. However:
Clicking in one of the fields makes the scroll wheel cycle through the field's list entries if the cursor is above the field.
If the cursor moves above the Tag Panel background, scrolling is back to move the Tag Panel.
Clicking the drop-down also enables scroll-wheel scrolling.
Entering data using the keyboard disables the ability to scroll using the scroll wheel to prevent accidental deletion of data. Using either key up or key down enables scrolling again.
I think that's it. Especially the idea to use click into a field to enable scrolling should also be in favor of those who like to use the scroll wheel to cycle to the fields contents. It's the best attempt to combine the two worlds, at least for today
Here is a preliminary version for you to try and test:
Please note that any of that might change or be removed again for a final release in case problems with the new implementation appear and even if you're not affected by those.
Just took that preliminary version for a spin. Personally, I love it. Fingers crossed this makes it into the next release version. Thanks for the swift work there, Florian.
I think so too. Good work.
You should add this to your list of "However":
- This does not affect multiline fields. These fields are always scrolled with the wheel if the cursor is on the field.
It think it is a good solution that multiline fields make an exception. With you present solution it is still possible to scroll within multiline fields without the need of clicking in the field.
Yes, it’s equivalent to moving the mouse, and not a special function of touchpad.
Thanks for looking at this quickly. I’ll give it a try later on today.
It is a big improvement! With a mouse, it is perfect for me.
But... I now notice a difference between mouse and touchpad behaviour on your point 1 (maybe a touchpad config issue - I looked and couldn't find one though). Two finger scroll on the touchpad starting over a field still scrolls the field and not the panel.
Thanks for your work on this
I can't reproduce what you're describing (with neither touchpad nor mouse). Here are the conditions in which scroll wheel / two-finger scrolling is enabled:
If you're aware of those conditions, can you describe in detail how you trigger the two-finger scrolling on the fields?
The following is using the touchpad, where two fingers is equivalent to the mouse scroll wheel, and single finger is just like moving the mouse:
- with the pointer over any part of the panel background, two fingers scrolls the panel
- with the pointer over a field (either with the focus, i.e. clicked and highlighted, or without the focus, i.e. not clicked and not highlighted) two fingers scrolls that field and not the panel
- once a field dropdown button is pressed and the list entries appear, two finger scrolling over any part of the dropdown does nothing; moving the pointer away with the list still showing then starting a two finger scroll causes the dropped down list entries to remain in the same screen location while the rest of the panel scrolls, so the dropdown list separates from the text entry line of the field (definitely not right).
Thanks for your additional tests which kept me perplexed and busy for quite some time. It's really hard to imagine the touchpad doing exactly the opposite of the mouse. Unfortunately, I haven't found anything in my code which might be related to the observations in your second point.
Can you maybe share details on the model of your laptop and the touchpad settings?
I've also did some tests regarding the third point (list detaching from the combo) and was able to reproduce this. It actually also behaves like that in the official version, but there it stops when reaching the next combo which makes the gap to be quite small. I'll fix that and prevent further scrolling of the Tag Panel if one of the fields is dropped down. Thanks for pointing!
I've now released this to the beta channel with Mp3tag v3.11f.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.