[Development] Controlling a QtQuick ListView using its contentY shall be supported or not?

Alan Alpert 416365416c at gmail.com
Tue May 21 20:02:41 CEST 2013


On Tue, May 21, 2013 at 10:32 AM, Albert Astals Cid
<albert.astals at canonical.com> wrote:
> TLDR: Controlling a ListView using its contentY doesn't work and we have a use
> case that needs it. I am volunteering to code the solution to make it work but
> the question is what solution the Qt project wants :-)

What I want to see is a better abstraction. ListView is complicated
enough already, and doesn't fit in well with the "primitives" goal of
QtQuick. So given infinite time, I'd go back to researching a better
abstraction so that you can just create your own ListView for custom
behavior - as easily as you'd create your own Button. Practically, I
think we'll have to compromise on that right now :( .

>
> THE PROBLEM
> Our design team wants a ListView with Header that behaves in a different way
> than the current Header component of ListView does. They want that if you
> scroll up when the Header is hidden the first thing that happens is that the
> header shows and then when the Header has been totally shown the list
> scrolling happens.
>
>
> THE SOLUTION
> A Flickable that controls the contentY of a ListView and the height of the
> Header
>   flickable_control_listview_without_sections.qml
> And it works :-) but...
>
>
> THE PROBLEM #2
> We want to have section headers in that listview and adding section headers
> makes lots of things go weird, you can see the problem in
>    flickable_control_listview.qml
> either by scrolling up when the list is at the top or by scrolling to the
> bottom and then pressing 1 to scroll up. The contentY of the list will not be
> at its expected location.
>
>
> THE SOLUTION #2
> I can workaround this by doing crazy things like on the listview
> onContentYChanged check if it is changing to the value I set it and if not
> fixing it (fixes the jittering going up from the top)
> and by remembering the last "originY" when pressing the 1 to go to the top
>    flickable_control_listview_workaround.qml
> I consider the changes between flickable_control_listview_workaround.qml and
> flickable_control_listview.qml a huge hack and something that should not be
> needed, but we could live with that
>
>
> THE PROBLEM #3
> We also want to have items with different sizes in the listview
>    flickable_control_listview_workaround_different_sizes.qml
> If you go to the end and then press 1 to scrol to the top you'll see that my
> workaround for the baseOriginY fails
>
>
> THE PROBLEM #4
> We also want to have problems if the list view contains complex loaders,
> haven't had time to create a simple test case for it
>
>
> THE REAL SOLUTION?
> We would like the code from flickable_control_listview_without_sections.qml to
> work on all the cases (sections, differently sized items, loader, etc) but we
> have been told that "Using contentY to control a listview is unsupported"
>
> We are hoping that this use case may make you change your opinion on that
> statement and accept patches that makes the code in
> flickable_control_listview_without_sections.qml (or something along the lines)
> work in all the other situations.
>
> In case you keep the statement that noone should use contentY to control
> listviews (why not make it read-only?) we see two solutions:

It's not read-only because it's known to be needed to hack things
together. It's what I'd call "sub-optimal". Even if we add better
support for dealing with contentX/Y manipulations, it would sill be
"unsupported" because that's not how ListView is supposed to be used.
It's supposed to just work the right way already, and you don't mess
with it (not a good answer for platform components, I know).

> 1) Add to ListView a enum that switches between the current Header
> hiding/showing behaviour and the one we want. Would you guys be interested in
> that feature to be merged upstream?

My concern here is the maintenance burden on an already massive class.
Conceptually I don't think adding this feature is an issue, but the
class is already hard-to-maintain so we need to keep a firm hand on
feature creep. I'd be happy to see a patch merged adding this if it's
really good quality and doesn't require major changes to ListView
internals. If you've got a patch already, I'd like to see it.

> 2) Reimplement our own ListView based on a Flickable so that it has the
> features we need. This is the solution we prefer the least since it would
> involve a lot of code duplication

This is supposed to be the correct solution for custom components with
QtQuick. You reimplement your own item with the behavior you want,
there's a little code duplication but it's all in QML and so easy that
it doesn't really matter.  But I can see how that approach just isn't
working with the view classes just yet.

> So what's your opinion, how should we implement the wanted behaviour with the
> current QtQuick items?

Don't stick to the current ones. Add new QtQuick items that are better
at this ;) .

--
Alan Alpert



More information about the Development mailing list