<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 26, 2015 at 6:39 PM, Linus Torvalds <span dir="ltr"><<a href="mailto:torvalds@linux-foundation.org" target="_blank">torvalds@linux-foundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So I mentioned to Dirk last week that I had found a regression in<br>
subsurface, but I hadn't pinpointed the cause. I spent some time<br>
trying to figure out why current subsurface does the wrong thing, and<br>
quite frankly, I *still* don't get it, but by now I'm blaming Qt5 for<br>
being horrible and wrong.<br>
<br>
The regression is that when I start up subsurface, it scrolls the<br>
divelist view so that the latest dive is at the top. "But that's what<br>
should happen!" I hear you say. No it's not, actually.<br>
<br>
The dive list should start with the latest *trip* visible, and that's<br>
how it used to be. But current subsurface starts up with the dive<br>
itself at the top, and the trip description has scrolled off the list<br>
view.<br>
<br>
Explicitly to avoid that, our common scrolling pattern is that we<br>
first scroll to the trip that the dive is in, and then scroll to the<br>
dive itself. The reason we do that is exactly so that the trip would<br>
be visible, unless the trip is so big that scrolling to the specific<br>
dive ends up scrolling the trip header off the screen.<br>
<br>
Now, the reason seems to be "currentChanged()", which does just<br>
<br>
        if (!current.isValid())<br>
                return;<br>
        scrollTo(current);<br>
<br>
but the reason I'm blaming Qt5 for this mess is that when I change it to do<br>
<br>
        if (!current.isValid())<br>
                return;<br>
        if (current.parent().isValid())<br>
                scrollTo(current.parent());<br>
        scrollTo(current);<br>
<br>
it still doesn't work. The last "scrollTo(current)" seems to scroll<br>
the parent (the trip) off the top of the window again, and you end up<br>
with the dive visible on the first line, but the trip not visible.<br>
<br>
Removing that final "scrollTo(current):" fixes things for me, but that<br>
will afaik do the wrong thing if a trip has a lot of dives, and we<br>
select one that isn't visible after you've scrolled the trip line to<br>
be visible.<br>
<br>
So I'm not sure what's going on. We've used some variation of that<br>
"scroll to parent, then scroll to dive" in several places, sometimes<br>
together with "expand(parent);" and "setAnimated(false/true);" around<br>
the parent scrolling so that we wouldn't be visibly jerking<br>
back-and-forth.<br>
<br>
The default for "scrollTo()" is ScrollHint::EnsureVisible, but the<br>
dive *is* visible when you've scrolled the trip to the top, so it<br>
shouldn't scroll the trip away. My *guess* is that this all happens<br>
before the window has been painted and setup completely, so it doesn't<br>
have its final size, leading to Qt5 thinking the dive isn't visible<br>
and scrolling to it, and scrolling away the trip line. But somebody<br>
who actually knows Qt is needed.<br>
<br>
Anybody who understands Qt? Tomaz? Thiago?<br>
<br>
And this doesn't show up for everything. If I do<br>
<br>
     ./build/subsurface dives/*.xml<br>
<br>
to try to show this with the test-dives we have, I don't get the same<br>
behavior as I do with . Then I *do* get the trip header visible. So if<br>
some Qt person doesn't go "I know what's up", and cannot reproduce<br>
this, I can send you all my dives in an xml file in private to help<br>
you see the behavior..<br>
<span class="HOEnZb"><font color="#888888"><br>
                          Linus<br></font></span></blockquote><div><br></div><div>Linus, </div><div><br></div><div>I have dirk`s dive file here, I`ll try to use them to check for this regression. </div></div><br></div></div>