Re: Middle scroll bar: get position from mouse instead of cursor?

[Scott Kostyshak <skostysh princeton edu>]

On Thu, Sep 18, 2014 at 4:00 AM, Kai Willadsen <kai willadsen gmail com> wrote:
> On Sep 18, 2014 5:46 AM, "Scott Kostyshak" <skostysh princeton edu> 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!

Scott