On 18 September 2014 22:55, Scott Kostyshak <[email protected]> wrote: > On Thu, Sep 18, 2014 at 4:00 AM, Kai Willadsen <[email protected]> > wrote: >> On Sep 18, 2014 5:46 AM, "Scott Kostyshak" <[email protected]> wrote: >>> >>> I really like the feature in Meld where you can put your mouse over >>> the middle bar and scroll to navigate the differences. From what I >>> understand, currently meld figures out what the "next" difference is >>> based on the cursor position. I think this is reasonable, but I wonder >>> if for most users' workflows it would make more sense to figure out >>> the next difference based on the line that is closest to the mouse >>> position when the user initiates the diff-scroll. >> >> I think it might be a good idea to look at changing the behaviour, but I >> think it's hard to know what will work without trying a few things. > > Makes sense. > >> My guess is that going by current mouse position might be weird, and >> something along the lines of "whatever chunk the cursor is in, if the cursor >> is on the screen, otherwise the chunk nearest to the middle of the screen" >> might be closer. I'm flexible on the first of those conditions... but I >> think we need something like it. We have logic for keeping the scrolled-to >> chunk near the middle of the screen, so maybe link up with that? > > Good ideas. If I understand, your point is that a user might want to > scroll to the next difference which is currently on the screen, but > the mouse just happens to be at the bottom. Under what I proposed, the > user would see undesired behavior because it would scroll to the next > chunk off the screen. I did not think about this case. > > Like you said, it will be hard to know without trying things. Please > let me know if you want me to test something. > >> Also, figuring out which chunk is nearest the middle of the screen (or the >> mouse cursor) will be a challenge as well, since you need to pick a side and >> handle inserts. > > True. > >>> For a use case, differences in my files are usually close together. So >>> there will be ten or so differences with a few lines of >>> non-differences in-between each of those ten; and then 200 lines later >>> there will be a similar cluster; and so on. I look at the differences >>> in the first cluster by navigating with normal scroll until I get to >>> the end of the cluster. Then my instinct is to use "diff-scroll" to >>> get to the next cluster, but because the mouse didn't move on normal >>> scroll, Meld takes me up instead of down, to the second difference in >>> the first cluster. All I need to do is remember to click before I >>> diff-scroll and it does what I want. I have trouble remembering this >>> though. >> >>> I'm fine with a 'wontfix' on this, but just wanted to check-in to see >>> if anyone else has thoughts. If this would be an OK feature request, I >>> can open a ticket. >> >> No, I've definitely done this before as well, so I'm very open to changing >> the way this works. However, the mapping from lines/pixels to chunks is some >> of our hairier code. (It probably shouldn't be, but... it is.) > > Ah, makes sense. > > Thanks for the explanations, Kai!
Just so that this doesn't get lost, I've filed a bug. https://bugzilla.gnome.org/show_bug.cgi?id=739184 If someone wanted to pick this up I'd gladly provide assistance. Working with the chunk list and getting the heuristic right will probably be a little bit weird, but not too challenging. cheers, Kai _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
