Hi, On 14 Jan 2017, at 17:24, Robin Burchell <robin.burch...@crimson.no<mailto:robin.burch...@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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development