Is QIdentityProxyModel the right solution for merging models?
-
If we have say a QAbstractListModel containing QList<QString> and we want to add say a bool to each of these QString's for another view and do not want to modify the base model,
Would having the second model as QIdentityProxyModel and set sourceModel as QAbstractListModel be the right approach?
Yes we get no sorting or filtering, which in this case i do not need however from examples in Qt Docs it seems like you use QIdentityProxyModel to have say custom properties and stuff based on items from sourceModel, I however want to hold a complete new QList corresponding to the initial items(and the base data as well ofc).
so the data function in the QIdentityProxyModel would return the new element. I'm just not sure how the data being changed in the sourcemodel will affect this. I'm guessing I'd have to have the remove , add & modify functions to correspond to the sourcemodel but just not sure if this is even the right approach or if there is a better solution.
-
So you want to add one or some more column(s) to the view, i.e. the view is supposed to display more columns than the original model has?
-
I do not want to add any more columns, its just a listview again in the derived model.
I'm just going to be drawing 2 option buttons on this derived model along with the original model's QString and track which option the user had chosen corresponding to the QString from the source model for each item.
-
Sorry, I don't get what you want. You're confusing things:
- the model holds the data
- the view draws the data
Where do you want to draw that "2 option buttons"? You cannot draw in a model.
I would suggest to create a mockup of both versions of your view in Qt Designer and post some screenshots. It looks as if it's hard to describe in text what you want to do.
-
Yeh sorry abt the confusion ...will do in 2 mins
-
"Image":http://imageshack.us/content_round.php?page=done&l=img405/3112/model12.png
Yes im aware of the model holding data and view painting it (with the delegate)
In the attached image The left side shows one view (listview) and right shows another view (listview)
So view with model 1 just has a string while view with model 2 also shows 2 option buttons since its model holds the state enabling the view's delegate to paint it appropriately
-
You cannot do that with model/view directly. The views do not support radiobuttons. You can only have check buttons here.
You could create a custom widget, holding a label with the color, a label with the string and two radio buttons and fill it's contents from the model. An a list widget you can then set an item widget.
Alternatively, you can omit the list widget completely (if you do not need special functionality of that on) and put all your custom widgets in a QScrollArea.
-
Hey Volker,
Cheers for helping, Im sorry but you've still got my doubt wrong. Im not having trouble with the "view or the display of the view or how to get my view to display this" thats why i said just consider the model being extended with a bool.
In your case a checkbox isChecked state.
I currently get the option buttons in my view by using QStyleOptions and then drawing them as controls and handling their events when triggered via setData and the delegate's editorEvent
@QApplication::style()->drawControl(QStyle::CE_PushButton,
&cancel_opt, painter);@
^^ All of this is fine for me. My doubt is just is it advisable to use QIdentityProxyModel to hold a seperate list of data points for each element of data from the source model.
So from the image if we simplify the list to hold
String A
String B
String CI need my model B to be consisiting of 3 elements such as
String A (Got From Model 1), true (Variable existing in this model corresponding to the item from Model 1)
and so on.
-
An identity proxy is used to manipulate the contents of a data point represented by a QModelIndex. You could implement this and, according to data already prepared in the original model, return data for different item roles (e.g. some user defined roles). In your second view you can query that roles from the proxy model. Or implement it just in the original model - that wouldn't add the overhead of an additional class.
-
Yeh that confirms my assumption of having the identity proxy model modify data of the original model than add to it.
And yes I guess just adding the required elements to the source model would negate the need for the overhead model but I was just trying to not use that approach cos it wasn't giving my model a clean interface.
I guess tho that I shall add it to the source model for the sake of performance than split the model and having to manually sync and keep mapping items from one model to another.
Thanks for your help :)
-
In my opinion, the proxy model is better suited for source models that you are not supposed to change or if you need to change the data for the very same role (e.g. translate a string, add some fancy background color or so). If you just add some more roles in the proxy, it is much more cleaner to add those to the original model in the first place.
-
Yeh I agree with the purpose of the QIdentityProxyModel however in my case
My Source Model holds contact info (Image, Name, Phone, D.O.B, ...)
Now in the second view consider im letting the end-user select contact's they want to add to a group
Now yes once done with the operation the selected contacts will belong to the Groups model or category but while its being created,
I'd have to show the user the list of his existing contacts and track who he wishes to add and who he doesnt. (Adding a flag in the source model will allow this easy and guess thats wht ill do) but in a practical stand it doesnt make sense to hold that info in a class/struct called contact.
-
[quote author="Nosf" date="1333717330"]
I'd have to show the user the list of his existing contacts and track who he wishes to add and who he doesnt. (Adding a flag in the source model will allow this easy and guess thats wht ill do) but in a practical stand it doesnt make sense to hold that info in a class/struct called contact.
[/quote]That depends on the implementation of your data model, of course :)
-
Indeed. It'll just be a case of performance if i just stick the flags into the source model / have another model and sync the contact part with the original model and build on top of it.
For now i'm gonna go with option 1 cos it seems obvious enuff to be a better performance solution