The desired behavior in your video can easily be accomplished by
keeping your old code, and NOT setting the flickable of the PageHeader.
Actually I think that is the best solution for the users too because
otherwise the header may be showing/hiding while you swipe left/right.
About your proposal,
1) I think nobody disagrees with that
2) I think the use case you mention where the topMargin is maintained when the
header is hidden conflicts with this. In this case, I interpret the hidden
header as a header that goes away by scrolling, so its exposed property becomes
false. The header should *not* change the topMargin when exposed changes,
because changes in topMargin may change exposed again, and it will cause the
page contents to jump around when the header hides.
Another issue with 2) is the implementation. It means that when you
unset a header.flickable, it will restore the previous topMargin. So
what happens when you have this case (which happens in practice when
apps have multiple headers on a Page (for example an edit header and a
regular header, of which only one is visible).
Say, we have this QML code:
Page {
id: page
PageHeader { id: header1; visible: page.header==header1; flickable:
pageFlickable }
PageHeader { id: header2; visible: page.header==header2; flickable:
pageFlickable }
header: editMode ? header2 : header1
property bool editMode: false
Flickable { id: pageFlickable }
}
Internally, header1 and header2 have a property "previousHeaderHeight" that
they use to restore the previous header height when flickable is unset or the
header becomes invisible.
Let's assume that header1 is always updated first by the qml engine, and then
header2 (that happened in my case).
1. editMode = true
// header 1 first reverts the previous header height
// header1: visible = false; pageFlickable.topMargin = 0;
// header2: visible = true; previousHeaderHeight = 0; pageFlickable.topMargin =
header2.height;
2. editMode = false
// header1: visible = true; previousHeaderHeight = header2.height;
pageFlickable.topMargin = header1.height;
// header2: visible = false; pageFlickable.topMargin = 0 (previousHeaderHeight);
So now we have the wrong topMargin because we don't know in which order
the properties of the different headers will be updated. The solution to
this is to make the headers not store previousHeaderHeight, or to set
the topMargin to header.height but to add to the topMargin when a header
is enabled with a flickable, and subtract the header height from it when
the header is invisible or the flickable is unset.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in
Ubuntu.
https://bugs.launchpad.net/bugs/1572525
Title:
[regression] Double header height is set as flickable topMargin
Status in Canonical System Image:
Incomplete
Status in ubuntu-ui-toolkit package in Ubuntu:
In Progress
Bug description:
Th attached test application works fine under qml-module-ubuntu-
components 1.3.1918+16.04.20160404-0ubuntu3 but breaks with the latest
1.3.1938+16.04.20160416. At a first examination, I believe that the
change which cause the regression is this one:
https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/invisible-
header-topmargin/+merge/290659
Run the attached test case with QML scene. You can scroll the view
horizontally to see the other model items. Under the old version of
the toolkit, all items have their page headers correctly aligned; with
the new version, an extra spacing is added below the header.
I found this bug while testing my ttrss app in rc-proposed; please
don't let this UITK version reach our users, as more apps might be
affected.
To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1572525/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
