[Development] Branch request: wip/itemviews in qtdeclarative

[J-P Nurmi]

Hi,

On 14 Jan 2017, at 17:24, Robin Burchell <robin.burchell at crimson.no<mailto:robin.burchell at crimson.no>> wrote:

I have a longer mental list of things that concern/bother me with
current model/views (some of which we've already discussed), maybe I
should try write that up in some form, if you think it might find it
helpful, but as I don't know how much time I'll be able to dedicate to
making this happen you may prefer me to hold my tongue :-)

There have been some discussions about rewriting the entire item-view framework. I personally believe that would be best done in a major release. :) I’m not planning to start writing a new item-view framework from scratch at this point, but refactor the internals so that it would be possible to reuse the same item view transitions etc. for a two-dimensional table view. In essence, I would like to avoid changing the basic principle how QQuickItemView works, but just split the reusable parts to a more abstract base class, for example. Ideally we wouldn’t have to touch ListView and GridView at all, and they'd continue to work at the same performance they have today.

+1 to having a branch for it (do you have a name in mind? wip/itemviews?
wip/tableview?)

I was thinking wip/itemviews, but I don’t mind wip/tableview either. :)

A thought, that came to mind while thinking about naming, though:
there's a lot of features listed here, and I would expect that they will
mature at different rates as some of them are more standalone, while
others might require more extensive (and careful!) work on the existing,
rather complicated code.

As a result, I start to wonder whether a single branch for all of this
makes sense, or whether it may make sense to do some smaller pieces
either directly on dev, or to use more than one WIP so that it's easier
to land stuff "when it's ready" rather than turning into a huge pile.

I have great confidence in you, of course, just trying to make life
easier along the way, so if you don't want to do this or feel that it
wouldn't be helpful to you, feel free to ignore the idea :)

Having more branches could be an option. All the tasks are somehow connected to each other, though, so I was thinking that it might be easiest to do it all in the same branch to avoid excessive conflicts and merging between multiple WIP-branches. The last two, SortFilterProxyModel and TreeModelAdaptor, would be the most logical ones to split to separate branches, but on the other hand, they also need to be implemented so that they play well with the rest.

(PS. I know you won't want to make hard promises, especially this early,
but do you have any idea what kind of timeframe you have in mind for
landing? Fingers crossed for "not 5.9"! ;-))

There’s so much to do that there is no way we could make all this happen before the 5.9 feature freeze in two weeks. :)

--
J-P Nurmi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170115/e3874c02/attachment.html>