Mobile: QML weirdness (likely Kirigami bug)

[Jan Mulder]

Ok, yesterday I wrote "So needed: revert both 17ec95e70c3ae58 and
40766db459b21.

Bug is related to the page stack and swiping through dives and returning
to the list by the breadcrumb (instead of the menu). Sometimes this
results in a page that shows both the divelist and the divedetail page
on top of each other. Easy to get to a sane state again from that (just
select the dive list from the menu), so not a real showstopper, but it
look ugly."

Further investigation shows that Kirigami commit 26b8bdea24c3930
(Refactor the Global ToolBar concept) first introduces this wrong
behavior in Subsurface-mobile. This is very non-trivial commit on the
Kirigami side, and I see nothing obvious that could explain the changed
behavior.

So the question is now: are we (Subsurface-mobile) doing something wrong
or is it the mentioned commit that messes things up for us (and prevents
us upgrading at this point).

I'm highly inclined to blame the Kirigami commit, as things as flicking
trough the page stack, using breadcrumb navigation, etc is 99% under
control of the Kirigami level of our app. Obviously, a small QML only
demonstrator of the issue could prove this.

It would be very nice if Marco could take a look as I believe no
Subsurface-mobile expertise on this QML/Kirigami level exists.

--jan

[Jan Mulder]

Post by Jan Mulder
Ok, yesterday I wrote "So needed: revert both 17ec95e70c3ae58 and
40766db459b21.
Bug is related to the page stack and swiping through dives and returning
to the list by the breadcrumb (instead of the menu). Sometimes this
results in a page that shows both the divelist and the divedetail page
on top of each other. Easy to get to a sane state again from that (just
select the dive list from the menu), so not a real showstopper, but it
look ugly."
Further investigation shows that Kirigami commit 26b8bdea24c3930
(Refactor the Global ToolBar concept) first introduces this wrong
behavior in Subsurface-mobile. This is very non-trivial commit on the
Kirigami side, and I see nothing obvious that could explain the changed
behavior.
So the question is now: are we (Subsurface-mobile) doing something wrong
or is it the mentioned commit that messes things up for us (and prevents
us upgrading at this point).
I'm highly inclined to blame the Kirigami commit, as things as flicking
trough the page stack, using breadcrumb navigation, etc is 99% under
control of the Kirigami level of our app. Obviously, a small QML only
demonstrator of the issue could prove this.
It would be very nice if Marco could take a look as I believe no
Subsurface-mobile expertise on this QML/Kirigami level exists.

Progress. I found a weird "clip: false" statement in our
Subsurface-mobile code (in ListView with id: diveDetailsListView). This
was changed over 1.5 year ago (commit dd1d90b5295b146e, with the
interesting description: QML UI: don't clip, At least that's what the
QML documentation recommends).

Not clipping seemed, in hindsight, exactly the problem that I found
while upgrading to a more recent SHA of Kirigami. So, a simple test
shows that clip: true solves the problem. Obviously, the Kirigami commit
26b8bdea24c3930 changed "something" that causes different behavior with
respect to this clipping of the Listview, but I cannot say that that is
a bug.

@Dirk. A little git question. What about reverting the 2 reverted
commits? Not sure how to handle that. Redo the 2 commits or just revert
the revert?

--jan

[Dirk Hohndel]

@Dirk. A little git question. What about reverting the 2 reverted commits? Not sure how to handle that. Redo the 2 commits or just revert the revert?

I'd just do a fresh commit and be done with it. No point in being overly fancy, IMHO

/D