Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-18 Thread Filippo Cucchetto 
Getting back to the real topic some thoughts about the current state of the
ItemViews and what we need
- TableView with horizontal virtualization
- TableViews probably should do column delegate caching
- Decide if we should go back to basic integer row/column fields (exposed
to delegates) or use QModelIndexes
This is important and could have big impacts on the design and api.
- Connected to the previous point we should decide if we want to make
QAbstractModel of QObject* first citizens
or not. In particular i found envaluable the design exposed by Stephen
Kelly here https://conf.qtcon.org/en/qtcon/public/events/355
Look at the video (
http://mirrors.fe.up.pt/kde-applicationdata/akademy/2016/355_how_to_interface_nonqt_model_code_with_qml.mp4)

 at time 18:26. Where the QModelIndexes are wrapped inside a QObject.
- The current way to expose data to the QML view delegates is inflexible
due to QAIM::roleNames(). First is not possible to emit a roleNamesChanged
without resetting the model. Second if the model contains a list
heterogeneous data the roleNames() should return a QMap that is the union
of all
the possible fields. For overcoming this problems most of the users return
a QObject*. This solution allows dynamic roleNames and remove the need
for writing lots of QAIM


F.

2017-01-18 8:49 GMT+01:00 Shawn Rutledge :

>
> > On 17 Jan 2017, at 14:29, Edward Welbourne 
> wrote:
> > One branch is dead but should perhaps be archived (i.e. moved to an
> > out-of-sight namespace): wip/tizen (qtdeclarative, qtsensors,
> > qtquickcontrols, qtbase).
>
> This was brought up before… Tizen still exists and Qt should still be able
> to run on it, IMO, supported or not.  So if the work was not finished, why
> kill it and have to start over later on?
>
> Otherwise someone had better archive it.  Ideally the archive should be
> accessible too.
>
> >  wip/qt5-nativetext (qtquickcontrols) 2012/Jul, Eskil Abrahamsen
> Blomfeldt
> >  wip/animation-refactor (qtdeclarative) 2012/Jan, Michael Brasser
> >
> >  wip/qa (qtlocation) 2011/Aug, shubinba 
> >  wip/v8 (qtscript) 2011/Jul, Peter Varga
> >  wip/experimental_scenegraphing (qtlocation) 2011/Jun, juhvu <
> qt-i...@nokia.com>
> >  wip/statemachine (qtdeclarative) 2011/Jun, Michael Brasser <
> michael.bras...@nokia.com>
> >  wip/textng (qtdeclarative) 2011/Jun, Yann Bodson  >
> >  wip/visuallistmodel (qtdeclarative) 2011/Jun, Andrew den Exter <
> andrew.den-ex...@nokia.com>
>
> Yeah sounds like I’d better look at a few of those.
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Shawn Rutledge 

> On 17 Jan 2017, at 14:29, Edward Welbourne  wrote:
> One branch is dead but should perhaps be archived (i.e. moved to an
> out-of-sight namespace): wip/tizen (qtdeclarative, qtsensors,
> qtquickcontrols, qtbase).

This was brought up before… Tizen still exists and Qt should still be able to 
run on it, IMO, supported or not.  So if the work was not finished, why kill it 
and have to start over later on?

Otherwise someone had better archive it.  Ideally the archive should be 
accessible too.

>  wip/qt5-nativetext (qtquickcontrols) 2012/Jul, Eskil Abrahamsen Blomfeldt
>  wip/animation-refactor (qtdeclarative) 2012/Jan, Michael Brasser
> 
>  wip/qa (qtlocation) 2011/Aug, shubinba 
>  wip/v8 (qtscript) 2011/Jul, Peter Varga
>  wip/experimental_scenegraphing (qtlocation) 2011/Jun, juhvu 
> 
>  wip/statemachine (qtdeclarative) 2011/Jun, Michael Brasser 
> 
>  wip/textng (qtdeclarative) 2011/Jun, Yann Bodson 
>  wip/visuallistmodel (qtdeclarative) 2011/Jun, Andrew den Exter 
> 

Yeah sounds like I’d better look at a few of those.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Edward Welbourne 
I wrote:
> Which reminds me, back in August I investigated then-current wip/s:
> http://lists.qt-project.org/pipermail/development/2016-August/026859.html

and Ossi brought git fetch's -p option to my attention.
Most of those mentioned before are still here, but:

> Two branches (only in qtbase) are done with and can be killed:
> wip/qstring-utf8
> wip/lite

wip/qstring-utf8 is already gone.

> I also observe wip/qtquickintergration in qt3d, which is clearly a typo
> for wip/qtquickintegration (which contains every commit of the typo-ed
> version).

This one has already been removed.

> Here's the list of all (other) currently live wip/s (in which modules)
> with date and author of the tip commit (on whichever module that's most
> recent):
[...]
>  wip/44-based (qtwebengine) 2015/Jul, Allan Sandfeld Jensen

This one is also gone.
All others are as described ...

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Pierre-Yves Siret 
Not really related to all the branch business going on, but I want to say
i'd gladly help and participate in this WIP, wherever that takes place.

2017-01-14 17:06 GMT+01:00 J-P Nurmi :

> Hi,
>
> Nice, looks great! It would be a very welcome contribution. We could
> polish and add the missing bits in the WIP branch if you’re interested? I
> haven’t thought about the exact details and requirements for
> SortFilterProxyModel yet, but we probably need to support multiple model
> columns. The plan is to make the new TableView support both, “proper” table
> models with multiple columns, and the old way of (ab)using roles as
> columns. :)
>
> --
> J-P Nurmi
>
> On 14 Jan 2017, at 14:06, Pierre-Yves Siret  wrote:
>
> Hi,
> I started implementing SortFilterProxyModel cause we needed it and
> published it here : https://github.com/oKcerG/SortFilterProxyModel
> For the moment it is not really documented or tested enough.
> I left it kinda alone for the past couple months but I plan to do more
> work on it, documenting, testing, adding some features and doing some
> refactoring.
> I also wanted to nominate it as a TP for 5.10.
> I guess it needs to be reworked before a potential inclusion in Qt (pimpl,
> using private headers from QAIM and ItemViews, etc.).
>
> I think what's interesting in my library is the ability to have multiple
> filters and sorters declaratively (as shown in the 2nd more advanced
> usecase of the readme), I also have a branch that I haven't pushed yet
> where you could define new roles defined from existing source roles.
>
> Where you thinking of that for the SortFilterProxyModel you wanted ?
>
> One of the shortcoming of my SFPM is that it is not really meant to be
> used for multiple columns, only roles, and it doesn't support tree models.
>
> Pierre-Yves Siret
>
> 2017-01-14 13:37 GMT+01:00 J-P Nurmi :
>
>> Hi,
>>
>> I'd like to request a WIP branch for the Qt Quick item views. There are
>> plenty of items on the roadmap/wishlist:
>>
>> - refactor QQuickItemView
>>   - add support for multiple delegate types (QTBUG-26681)
>>   - add support for multi-selection
>>   - add support for multiple columns
>> - implement TableView (QTBUG-51710)
>> - implement HeaderView
>> - implement SortFilterProxyModel
>> - productize TreeModelAdaptor (QTBUG-54390)
>>
>> Early feedback from the CI system would be invaluable.
>>
>> --
>> J-P Nurmi
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Edward Welbourne 
Oswald Buddenhagen:
> speaking of how hard is to get branches: the policy is quite clear that
> done (and abandoned) branches should be deleted (or moved to a hidden
> namespace, if you insist on archiving your throw-away branch). they
> aren't, they are piling up. what exactly do you expect in return?

Which reminds me, back in August I investigated then-current wip/s:
http://lists.qt-project.org/pipermail/development/2016-August/026859.html

Two branches (only in qtbase) are done with and can be killed:
wip/qstring-utf8
wip/lite

One branch is dead but should perhaps be archived (i.e. moved to an
out-of-sight namespace): wip/tizen (qtdeclarative, qtsensors,
qtquickcontrols, qtbase).

I also observe wip/qtquickintergration in qt3d, which is clearly a typo
for wip/qtquickintegration (which contains every commit of the typo-ed
version).

Ossi, would you take care of those ?


Here's the list of all (other) currently live wip/s (in which modules)
with date and author of the tip commit (on whichever module that's most
recent):

  wip/animation (qt3d) 2017/Jan, Sean Harmer
  wip/pointerhandler (qtdeclarative) 2017/Jan, Shawn Rutledge
  wip/qtquickintegration (qt3d) 2017/Jan, Sean Harmer
  wip/scenegraphng (qtdeclarative) 2017/Jan, Laszlo Agocs

  wip/qbs (qtbase) 2016/Dec,  Christian Kandeler
  wip/qtwebkit/next (qt5) 2016/Oct, Konstantin Tokarev
  wip/particles (qt3d) 2016/Sep, Liang Qi
  wip/next (qtwebkit) 2016/Aug, Liang Qi
  wip/remac (qtbase) 2016/Aug, Jan Arve Saether
  wip/nacl (qtbase, qtdeclarative) 2016/Jul, Gabriel de Dietrich
  wip/speech-recognition (qtspeech) 2016/Apr, Frederik Gladhorn

  wip/win (qtconnectivity) 2015/Dec, Alex Blasche
  wip/network-test-server (qtbase) 2015/Oct, me
  wip/dbus (qtdeclarative) 2015/Oct, Sérgio Martins
  wip/47-based (qtwebengine) 2015/Oct, Allan Sandfeld Jensen
  wip/mir (qtbase) 2015/Aug, Paul Olav Tvete; Canonical wanted it in 2016/Aug
  wip/highdpi (qtbase) 2015/Jul, Paul Olav Tvete; probably dead ?
  wip/44-based (qtwebengine) 2015/Jul, Allan Sandfeld Jensen
  wip/threading (qtcanvas3d) 2015/Jul, Miikka Heikkinen

  wip/gc (qtdeclarative) 2014/Apr, Thiago Macieira
  wip/calendar (qtquickcontrols) 2014/Feb, Mitch Curtis

  winrt (qtbase) 2013/Sep,  Andrew Knight 
  wip/winrt (qttools) 2013/Aug, Andrew Knight 
  wip/android (qtscript, qtdoc, qtimageformats, qtquick1,
   qtgraphicaleffects) 2013/Feb, Eskil Abrahamsen Blomfeldt

  wip/qt5-nativetext (qtquickcontrols) 2012/Jul, Eskil Abrahamsen Blomfeldt
  wip/animation-refactor (qtdeclarative) 2012/Jan, Michael Brasser

  wip/qa (qtlocation) 2011/Aug, shubinba 
  wip/v8 (qtscript) 2011/Jul, Peter Varga
  wip/experimental_scenegraphing (qtlocation) 2011/Jun, juhvu 

  wip/statemachine (qtdeclarative) 2011/Jun, Michael Brasser 

  wip/textng (qtdeclarative) 2011/Jun, Yann Bodson 
  wip/visuallistmodel (qtdeclarative) 2011/Jun, Andrew den Exter 


and I am naturally suspicious of those whose last commit is from an
e-mail @nokia, all from 2011; these sound suspiciously dead.
Please review those you know anything about ... especially the old ones.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-17 Thread Oswald Buddenhagen 
On Mon, Jan 16, 2017 at 09:59:42PM +, J-P Nurmi wrote:
> > On 16 Jan 2017, at 16:24, Oswald Buddenhagen  
> > wrote:
> > 
> > On Sat, Jan 14, 2017 at 12:37:06PM +, J-P Nurmi wrote:
> >> Early feedback from the CI system would be invaluable.
> >> 
> > note that nowadays you can explicitly schedule CI runs on arbitrary
> > pending changes.
> > of course, that's not the only _possible_ reason for wanting a branch,
> > but if it's the only _actual_ reason, then it may make sense to change
> > the plan.
> 
> 
> I’m expecting the refactoring work to generate quite a large amount of 
> commits. I’d prefer to do it in small steps to reduce the risk of breaking 
> things. This would be a throw-away branch. No merging to the mainline, but 
> ready features would be picked by hand and submitted for review.
> 
fair enough. note that you're adding to the CI load, so try to batch
your integrations in as far as reasonable. as always, actually.
you didn't specify the source, so i assumed dev.

speaking of how hard is to get branches: the policy is quite clear that
done (and abandoned) branches should be deleted (or moved to a hidden
namespace, if you insist on archiving your throw-away branch). they
aren't, they are piling up. what exactly do you expect in return?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-16 Thread Shawn Rutledge 

> On 14 Jan 2017, at 13:37, J-P Nurmi  wrote:
> 
> Hi,
> 
> I'd like to request a WIP branch for the Qt Quick item views. There are 
> plenty of items on the roadmap/wishlist:

+1 from me as well.

I think the back pressure about creating branches is really holding us back - 
you should be able to click a button somewhere and get one.  The more people 
expect dev branch to be stable, and whining when it doesn’t always build (which 
was a frequent problem 5 years ago, but not very often anymore), the more we’re 
going to need feature branches to do actual development work.  Having a big 
pile of patches on gerrit always feels disorganized and frustrating.  I’m sure 
it will be pointed out again that every patch is its own branch, but it doesn’t 
feel like it’s going anywhere when you work like that, and reviewers just keep 
ignoring your stuff, and nobody can get a linear view of where you’re going, 
because the “head” of the linked list is always changing.

I’ll be curious to see though whether a throwaway branch really works out 
better for you than a direct-merging one.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-16 Thread Oswald Buddenhagen 
On Sat, Jan 14, 2017 at 12:37:06PM +, J-P Nurmi wrote:
> Early feedback from the CI system would be invaluable.
> 
note that nowadays you can explicitly schedule CI runs on arbitrary
pending changes.
of course, that's not the only _possible_ reason for wanting a branch,
but if it's the only _actual_ reason, then it may make sense to change
the plan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-16 Thread Edward Welbourne 
Robin Burchell
> 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 :-)

Sounds like a wiki page waiting to be written.
Add it to [[Category:Developing Qt]] and maybe we'll combine it with
other Model/View pages later to make a sub-category.
Or even revive https://wiki.qt.io/Model-View-Design-Issues

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-15 Thread Robin Burchell 
Hi,

On Sun, Jan 15, 2017, at 12:24 PM, J-P Nurmi wrote:
> 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 guess you're talking about the generic positioner-based view stuff
here, but I wasn't thinking quite so ambitious. That is indeed one thing
that is still bouncing around my head, but I suspect it will stay there
for some time more :)

More generally, I don't disagree that such a thing would be a major
version change, or at least, done in a separate import. Anyway, I'll try
write a longer mail about some of my thoughts on this stuff so they have
a place in the public record, split off from this thread, as it is
definitely a bit of a tangent.

> +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. :)

If your specific goal here is to provide enablers for tableview, then
I'd go for wip/tableview.

> 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.

Yes, that's pretty much the sort of division I was thinking; and
especially if Pierre-Yves can help with contributing on the SFPM part,
perhaps that's a good candidate for doing "separately". I understand and
agree with the need for unity, of course, but perhaps communication can
help to some degree there. Anyway, it was just a suggestion. I'll leave
the "how" to you people, you know the details of this work better than I
:)

> 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. :)

Text doesn't quite convey the emotion I meant that statement to evoke
;-); but I guess then you're thinking something like 5.11 (potentially
earlier, if the planets align correctly)? Again, I'm not expecting
promises here, just a rough idea would be a help so I can know when I
need to start trying to pay closer attention to anything touching the
area.

Thanks again.

-- 
  Robin Burchell
  ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-15 Thread J-P Nurmi 
Hi,

> On 14 Jan 2017, at 19:20, Mark Gaiser  wrote:
> 
> That new TableView is really going to support models that derive 
> QAbstractTableModel? Without any changes required on the model side? So if it 
> works in QTableView (C++ widget) then it will work in the new TableView (QML 
> component)?
> That would be a big win!
> 
> Would the view also have transition support?
> The current TableView [1] component doesn't have it, the GridView [2] 
> component does, but it basically only eats list models and requires role foo..

Yes, we’re well aware of the limitations and quirks of the TableView in Qt 
Quick Controls 1. :) QAbstractTableModel support is considered as a requirement 
for the new TableView. I’m quite confident we can base the new TableView on the 
same item-view framework ListView and GridView use, so it can support the same 
item view transitions and so on.

> Do you plan the new TableView to be a styled component (like one of the many 
> other control components) or a bare component where the user needs to define 
> the delegates for the contents, header and sidebar?
> My preference would be a bare component.

The plan is that the new TableView would be on the same line with ListView and 
GridView. The visual delegates are left to the user to provide. For those who 
want ready-made styles, we provide a bunch of simple styled delegates in Qt 
Quick Controls 2.

--
J-P Nurmi


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-15 Thread J-P Nurmi 
Hi,

On 14 Jan 2017, at 17:24, Robin Burchell 
> 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

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-14 Thread Mark Gaiser 
On Sat, Jan 14, 2017 at 5:06 PM, J-P Nurmi  wrote:

> Hi,
>
> Nice, looks great! It would be a very welcome contribution. We could
> polish and add the missing bits in the WIP branch if you’re interested? I
> haven’t thought about the exact details and requirements for
> SortFilterProxyModel yet, but we probably need to support multiple model
> columns. The plan is to make the new TableView support both, “proper” table
> models with multiple columns, and the old way of (ab)using roles as
> columns. :)
>
>
That new TableView is really going to support models that derive
QAbstractTableModel? Without any changes required on the model side? So if
it works in QTableView (C++ widget) then it will work in the new TableView
(QML component)?
That would be a big win!

Would the view also have transition support?
The current TableView [1] component doesn't have it, the GridView [2]
component does, but it basically only eats list models and requires role
foo..

Do you plan the new TableView to be a styled component (like one of the
many other control components) or a bare component where the user needs to
define the delegates for the contents, header and sidebar?
My preference would be a bare component.

Lots of questions ;)

[1] http://doc.qt.io/qt-5/qml-qtquick-controls-tableview.html
[2] http://doc.qt.io/qt-5/qml-qtquick-gridview.html


> --
> J-P Nurmi
>
> On 14 Jan 2017, at 14:06, Pierre-Yves Siret  wrote:
>
> Hi,
> I started implementing SortFilterProxyModel cause we needed it and
> published it here : https://github.com/oKcerG/SortFilterProxyModel
> For the moment it is not really documented or tested enough.
> I left it kinda alone for the past couple months but I plan to do more
> work on it, documenting, testing, adding some features and doing some
> refactoring.
> I also wanted to nominate it as a TP for 5.10.
> I guess it needs to be reworked before a potential inclusion in Qt (pimpl,
> using private headers from QAIM and ItemViews, etc.).
>
> I think what's interesting in my library is the ability to have multiple
> filters and sorters declaratively (as shown in the 2nd more advanced
> usecase of the readme), I also have a branch that I haven't pushed yet
> where you could define new roles defined from existing source roles.
>
> Where you thinking of that for the SortFilterProxyModel you wanted ?
>
> One of the shortcoming of my SFPM is that it is not really meant to be
> used for multiple columns, only roles, and it doesn't support tree models.
>
> Pierre-Yves Siret
>
> 2017-01-14 13:37 GMT+01:00 J-P Nurmi :
>
>> Hi,
>>
>> I'd like to request a WIP branch for the Qt Quick item views. There are
>> plenty of items on the roadmap/wishlist:
>>
>> - refactor QQuickItemView
>>   - add support for multiple delegate types (QTBUG-26681)
>>   - add support for multi-selection
>>   - add support for multiple columns
>> - implement TableView (QTBUG-51710)
>> - implement HeaderView
>> - implement SortFilterProxyModel
>> - productize TreeModelAdaptor (QTBUG-54390)
>>
>> Early feedback from the CI system would be invaluable.
>>
>> --
>> J-P Nurmi
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-14 Thread Robin Burchell 
Hi,

I (of course) wholeheartedly support work in the model/view area. It's
something that could use some TLC, and I'm excited to see what you have
cooking!

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 :-)

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

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 :)

(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"! ;-))

-- 
  Robin Burchell
  ro...@crimson.no

On Sat, Jan 14, 2017, at 01:37 PM, J-P Nurmi wrote:
> Hi,
> 
> I'd like to request a WIP branch for the Qt Quick item views. There are
> plenty of items on the roadmap/wishlist:
> 
> - refactor QQuickItemView
>   - add support for multiple delegate types (QTBUG-26681)
>   - add support for multi-selection
>   - add support for multiple columns
> - implement TableView (QTBUG-51710)
> - implement HeaderView
> - implement SortFilterProxyModel
> - productize TreeModelAdaptor (QTBUG-54390)
> 
> Early feedback from the CI system would be invaluable.
> 
> --
> J-P Nurmi
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-14 Thread J-P Nurmi 
Hi,

Nice, looks great! It would be a very welcome contribution. We could polish and 
add the missing bits in the WIP branch if you’re interested? I haven’t thought 
about the exact details and requirements for SortFilterProxyModel yet, but we 
probably need to support multiple model columns. The plan is to make the new 
TableView support both, “proper” table models with multiple columns, and the 
old way of (ab)using roles as columns. :)

--
J-P Nurmi

On 14 Jan 2017, at 14:06, Pierre-Yves Siret 
> wrote:

Hi,
I started implementing SortFilterProxyModel cause we needed it and published it 
here : https://github.com/oKcerG/SortFilterProxyModel
For the moment it is not really documented or tested enough.
I left it kinda alone for the past couple months but I plan to do more work on 
it, documenting, testing, adding some features and doing some refactoring.
I also wanted to nominate it as a TP for 5.10.
I guess it needs to be reworked before a potential inclusion in Qt (pimpl, 
using private headers from QAIM and ItemViews, etc.).

I think what's interesting in my library is the ability to have multiple 
filters and sorters declaratively (as shown in the 2nd more advanced usecase of 
the readme), I also have a branch that I haven't pushed yet where you could 
define new roles defined from existing source roles.

Where you thinking of that for the SortFilterProxyModel you wanted ?

One of the shortcoming of my SFPM is that it is not really meant to be used for 
multiple columns, only roles, and it doesn't support tree models.

Pierre-Yves Siret

2017-01-14 13:37 GMT+01:00 J-P Nurmi >:
Hi,

I'd like to request a WIP branch for the Qt Quick item views. There are plenty 
of items on the roadmap/wishlist:

- refactor QQuickItemView
  - add support for multiple delegate types (QTBUG-26681)
  - add support for multi-selection
  - add support for multiple columns
- implement TableView (QTBUG-51710)
- implement HeaderView
- implement SortFilterProxyModel
- productize TreeModelAdaptor (QTBUG-54390)

Early feedback from the CI system would be invaluable.

--
J-P Nurmi


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

2017-01-14 Thread Pierre-Yves Siret 
Hi,
I started implementing SortFilterProxyModel cause we needed it and
published it here : https://github.com/oKcerG/SortFilterProxyModel
For the moment it is not really documented or tested enough.
I left it kinda alone for the past couple months but I plan to do more work
on it, documenting, testing, adding some features and doing some
refactoring.
I also wanted to nominate it as a TP for 5.10.
I guess it needs to be reworked before a potential inclusion in Qt (pimpl,
using private headers from QAIM and ItemViews, etc.).

I think what's interesting in my library is the ability to have multiple
filters and sorters declaratively (as shown in the 2nd more advanced
usecase of the readme), I also have a branch that I haven't pushed yet
where you could define new roles defined from existing source roles.

Where you thinking of that for the SortFilterProxyModel you wanted ?

One of the shortcoming of my SFPM is that it is not really meant to be used
for multiple columns, only roles, and it doesn't support tree models.

Pierre-Yves Siret

2017-01-14 13:37 GMT+01:00 J-P Nurmi :

> Hi,
>
> I'd like to request a WIP branch for the Qt Quick item views. There are
> plenty of items on the roadmap/wishlist:
>
> - refactor QQuickItemView
>   - add support for multiple delegate types (QTBUG-26681)
>   - add support for multi-selection
>   - add support for multiple columns
> - implement TableView (QTBUG-51710)
> - implement HeaderView
> - implement SortFilterProxyModel
> - productize TreeModelAdaptor (QTBUG-54390)
>
> Early feedback from the CI system would be invaluable.
>
> --
> J-P Nurmi
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development