GNOME Bugzilla – Bug 740134
Tag view list scrolls to end of selection when selecting up but not when selecting down
Last modified: 2014-12-22 07:57:49 UTC
EasyTAG scrolls the selected listed of tracks to the end of the selection when you select files from the bottom of the range upwards but not when selecting from the top of the range going downwards. Steps to reproduce (what I mean by "selecting up" -- defining a contiguous range going from top of range to bottom of range): 1. Start EasyTAG in a folder with a lot of files -- enough so that EasyTAG can't fit all of the file metadata in the view and the scrollbar has plenty of room to go up and down. Note approximately how many files are visible in the view (I'll guess it's 20 files in this example). 2. Scroll to about midway in the list of files and select one file. 3. Scroll up so your selected file is not visible in the view and shift-click a file thus defining a single contiguous range of selected files. 4. Note how EasyTAG has scrolled the selection down so that the bottom of the range (the last file in the contiguous selection) is visible. Compare that to the following steps which describe what I mean by "selecting down" -- defining a contiguous range going from bottom of range to top of range: 1. Using the same EasyTAG instance in the same folder as above, scroll to about midway in the list of files and single-click (select) a file. 2. Scroll down so your selected file is not visible in the view and shift-click a file thus defining a single contiguous range of selected files. 3. Note how EasyTAG has not scrolled the selection at all. Whatever was visible before you defined the end of the range is still visible now. This is the behavior I expected regardless of the directionality of my range (what I'm calling "selecting up" and "selecting down" for lack of better terms). This inconsistency is annoying and can be worked around. Unfortunately this annoyance gives the impression that EasyTAG didn't properly note the selection because when you select up you only see the lowest selected entry selected in the view. It's not until you scroll up that you see EasyTAG noted the selection properly and you can go on with the rest of your file processing. I expected the view would not scroll at all unless scrolling is necessary to show me what I'm clicking on, which is the way selecting down appears to work.
There is a TODO in et_browser_set_row_visible() to only scroll if the row to be scrolled to is not already visible (although I think that in modern versions of GTK+ this is handled by the toolkit). However, the real oddity is that EasyTAG scrolls to the bottom of the selection, which is (apparently) intentional according to the comments in Browser_List_Row_Selected(). If I simply remove that signal handler, the behaviour is the same in both selection directions: https://people.gnome.org/~davidk/easytag/easytag-simplify-selection.webm That feels better to me, does it seem right to you?
Yes, that looks right (and consistent) to me. Thanks for looking into this and the thanks for the video! I have to admit, I don't understand why one would want to scroll to the bottom of the selection on selecting the top of the range, much less only do this only in certain circumstances. This behavior strikes me as weird because I can't think of another program that does this, therefore I've never come to associate this with normal or desirable behavior. So if there's some advantage to the current (apparently intentional) behavior, I await enlightenment.
I investigated this a bit further, and found that there was code to store a reference to each row before it was selected, apparently with the intent of showing the about-to-be-selected row in the tag area. This does not seem to play well with selecting ranges. A better way of handling this is to use the current cursor row to determine which file will appear in the tag area. I made such a change and pushed it to master as 72ec45e6bb209e9029ba13f6663d0f0a48ab8378. This works well in my testing, but I am unsure whether any other code depended on the odd selection behaviour. I will backport the change to the easytag-2-2 branch after a bit more testing.
*** Bug 741845 has been marked as a duplicate of this bug. ***