[RFC - tentartive PATCH] Fix initial scrolling problem

[Dirk Hohndel]

On Sun, May 10, 2015 at 04:01:58PM -0700, Linus Torvalds wrote:
> The initial selection change signal seems to potentially be sent
> before the listview is even visible when we do the first "scrollTo()"
> to the currently selected dive.
> 
> That, in turn, seems to result in that when the listview is actually
> shown, it will be scroll the trip description off the visible area,
> and force the current dive to be shown at the very top of the
> divelist. Which is not very nice: we do want to scroll to the current
> dive, but we don't want to hide the current trip in the process.
> 
> Ignoring the selection change if the listview isn't even visible seems
> to fix things for me.

It fixes it for me as well. Good work.
After you told me about it (and then again after you sent the email) I
tried a number of things and none seemed to work. This looks completely
unintuitive but it does get the job done. Who'd have thunk.

> This patch works for me, but the reason it has that "RFC - tentative"
> is that I just don't know the Qt initial exposure rules. The way I
> zoomed in on this was to just print debug messages for every
> scrollTo(), and figuring out which one triggered, and noticing that
> "isVisible()" isn't actually true for this case.
> 
> Put another way: I don't have any idea what I'm doing. I'm not a GUI
> person. I also suspect that this whole behavior is timing-sensitive,
> because it doesn't happen for me on smaller test-cases I've tried. So
> I'd *really* like somebody like Tomaz or Thiago at least say "ok, that
> isn't entirely insane".

So I'm clearly not the resident Qt expert, either. But what I can say is
that I don't see how the patch could hurt. It simply doesn't scroll to the
current item if the widget isn't visible. And I do see that it helps with
the scrolling situation.

So I'll take it and if Tomaz hates it or has a better fix we can simply
revert it.

Thanks, Linus

/D