** Tags added: regression-proposed
** Changed in: canonical-devices-system-image
Milestone: None => 11
** Changed in: canonical-devices-system-image
Assignee: (unassigned) => Zoltan Balogh (bzoltan)
** Changed in: canonical-devices-system-image
Status: New => Incomplete
--
You
I'm not the developer of PageHeader, but I had a look at the code, and
it seems that's the expected outcome.
When PageHeader.flickable is set, PageHeader adds its height to the
topMargin to ensure all the content is visible.
In your case, when PageHeader.flickable is set both PageHeader and you
a
I understand it's the expected outcome, but why was it changed? None of the
bugs which the MP claimed to fix require this change.
Actually, if you look at line 209 of the diff (at
https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/invisible-header-topmargin/+merge/290659)
you'll see that a u
** Changed in: ubuntu-ui-toolkit (Ubuntu)
Assignee: (unassigned) => Tim Peeters (tpeeters)
** Changed in: ubuntu-ui-toolkit (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu
because topMargin should be available for the dev to use it for whatever
he needs it to. The developer should not have to mind about setting it
to accomodate a behaviour that is handled by PageHeader.
So, on one side, you have to make space for the header, on the other
side, you should (must, I'd
I will stop here as, as I said, I'm not the maintainer of that
component, nor am I in the SDK team :)
I've just been involved in the discussion so I wanted to provide some
info about why that works the way it does.
The documentation, to me, looks outdated :)
--
You received this bug notificatio
As Andrea said, this is the expected behavior.
The PageHeader will update the topMargin of the flickable that you set
in order to ensure enough space for the header when it is visible. In
addition to that, you set another topMargin inside the Flickable. We had
to make a choice to either let the ap
** Branch linked: lp:~tpeeters/ubuntu-ui-toolkit/topMargin-bug1572525
--
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 he
** Changed in: ubuntu-ui-toolkit (Ubuntu)
Status: New => In Progress
--
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 hea
Hi Tim, I don't think that this behavioural change is related to the
bugs fixed by that MP. I believe that those bugs can be fixed, while
retaining the old (and documented) behaviour of setting the flickable
margin to the height of the header. All what those bugs say, is about
the margin behaviour
Those bugs could not be fixed without changing the behavior. The problem
was that we stored the old topMargin and set that back when a flickable
was unset from the Header. However, there are cases (even in our UITK
gallery, outside of our control depending on the QML engine) when Header
instances a
Alberto, may I ask what is the reason you are settjng the ListView
delegate's flickable the one to control the header movement? That seems
to be a bit of a bad idea tbh...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubunt
The attached MR will clarify the behavior by updating the Header docs.
--
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 h
Hi guys! I have to say, that I completely disagree with the proposed
solution and would like us to stop for a moment and think about the
issue again. I'm attaching a video which shows how the application is
working on the current OTA and how I think it should continue working.
The thing I want to
For a comparison, here's how the application would work with the new
UITK and Tim's workaround. I don't think it's an improvement at all,
especially because the back page action repeated on all items is rather
confusing (am I scrolling through a page stack here? Will I go to the
previous element if
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,
** Branch linked: lp:~mardy/ubuntu-ui-toolkit/header-1572525
--
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 s
Hi Tim, I attached a branch which should give you an idea of how I think
the problem can be solved. Beware, I didn't test it and it's not
complete (it doesn't adjust contentY yet), it's just to be used as a
starting point.
In that branch I'm attaching some extra data to the flickable (using
setPr
Alberto, I disagree with your solution. I think the behavior that we
have now is correct because it keeps the original topMargin of the
flickable for the part of the flickable that will be visible below the
header (in y-direction).
Your video shows a very special case: A Page with a header, and a
Tim, I understand that you are a bit of a perfectionist, and that's very
good :-) But here you want to "fix" a bug that no one reported, and that
breaks a completely weird use-case that never actually worked (why would
want to have additional margin below the header, that could not be
implemented w
** Changed in: canonical-devices-system-image
Status: Incomplete => In Progress
** Changed in: canonical-devices-system-image
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-ui-t
@Alberto, I proposed before that you lock your header so that it does
not auto-hide, because if your header is not locked, and you change the
header.flickable while the user is scrolling horizontally in the
ListView, you will have weird header behavior where it jumps in and out
of the view while sc
After some more discussion on IRC, for Alberto's use case he will lock
the header. I will close this bug. In UITK2 we probably will not try to
automatically set the topMargin of the flickable, and leave it to the
app developer so there will be full freedom (at the cost of a few extra
lines of code
On 20/04/2016 16:29, Andrea Bernabei wrote:
> because topMargin should be available for the dev to use it for whatever
> he needs it to. The developer should not have to mind about setting it
> to accomodate a behaviour that is handled by PageHeader.
>
> So, on one side, you have to make space for
On 04/26/2016 06:18 PM, Tim Peeters wrote:
> @Alberto, I proposed before that you lock your header so that it does
> not auto-hide, because if your header is not locked, and you change the
[...]
I don't think that a meeting with the designers is necessary, and I can
certainly live with the fixed h
25 matches
Mail list logo
