Moving items between two views.

[YuriyRusinov]

Hello, All !

I have two similar QTreeView's with sorted data in everywhere for move data from one model to another.
QTreeView
|
QSortFIlterProxyModel
||
QStandardItemModel.

I manipulate with model data using methods data()/setData() from one model to another, but if I try to select very many rows (~1000) then time of moving became very very big. Any ideas ? Can I do it without copying ?

Thanks in advance.

[wysota]

How do you perform the insertion into a model?

[YuriyRusinov]

How do you perform the insertion into a model?

Using insertRows function.

[wysota]

Try implementing a custom method that will add all the items at once instead of adding one by one. Blocking the signals for the time of insertion might speed up the action as well.

[YuriyRusinov]

OK, Which way I have to block signals from models ? I use QStandardModel class.

[fullmetalcoder]

OK, Which way I have to block signals from models ? I use QStandardModel class.
QObject::blockSignals(bool)

[YuriyRusinov]

Thanks, model works fine. But one more question is arisen. Because these views have one type of data, can I define one source model for all and two proxy models for sorting and filtering. Such as
View
||
<Sort and Filter proxy>
||
<Displayed custom proxy>
|
Source Model ?

Would it faster ?

Thanks in advance.

[fullmetalcoder]

Thanks, model works fine. But one more question is arisen. Because these views have one type of data, can I define one source model for all and two proxy models for sorting and filtering. Such as
View
||
<Sort and Filter proxy>
||
<Displayed custom proxy>
|
Source Model ?

Would it faster ?

Thanks in advance.
I don't understand you... You used two views with different models in them and moved items from a view to another rigth? So it wouldn't make sense to make them share a single model through proxies... Unless you change the design of your app and stop moving items from a view to another (which does not mean that the user can move them, just that filter rules change:)). If you do so it would probably be faster and less memory consumming because it would avoid some duplications and deep copies but I'm not sure how much... I guess it depends on what you're actually doing.

[YuriyRusinov]

These views have to be contains single items set, but every item have to be contained in one and only one view. Before this I do it using available model and selected model. This approach results in very slow time in interaction. Now I try to another approach to have single source model and different list of displayed data.

[wysota]

If you mean applying two different model proxies to the same source model and using those two resulting models for different views, then the answer is "yes, you can do that". Then if you manipulate the source model both views will be updated accordingly through the proxies.

[fullmetalcoder]

These views have to be contains single items set, but every item have to be contained in one and only one view. Before this I do it using available model and selected model. This approach results in very slow time in interaction. Now I try to another approach to have single source model and different list of displayed data.
Well I suggest you add a flag/property/whatever-you-name-it to your items which will define in which view it shall be displayed. Then each view will be fed by a proxy which will display only items with the matching flag. This flag can be any type for which it exists comparisions operators (QString, QChar, QPoint, ...) but an integer is probably the best solution if you're looking for speed.

Then moving an item from a view to another will be as simple as :

changing the aforementionned flag
notifying a change to the view (either a dataChanged(parentIndex, parentIndex) or a complexer but possibly more efficient computation and {begin,end}{Insert,Remove}Rows()...):)

[wysota]

If both views don't share any data from the model (for example one displays all odd rows and the other all even rows), then I'd say it might be better to have two separate source models. But it is hard to make that a rule of thumb.