| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
Hi I am implementing a list of devices that will be displayed for multiple access levels. Each access level can stipulate whether the members have permission to use a device from the list. I have implemented this as a checkable Model that stores the CheckState in the data items. This works well but doesn't allow me to have multiple, separate check states using the same data model. My first thought would be to use the QAbstractProxyModel to implement a checkable proxy so that I could keep a static data model with different views. Has anyone tried this? Also would a QItemSelectionModel be a better option? Any suggestions would be appreciated. Ciao Grant
Attachment:
Attachment:
smime.p7s
Attachment:
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Message 2 in thread
On mandag den 5. November 2007, Grant Carver wrote:
> Hi
>
> I am implementing a list of devices that will be displayed for multiple
> access levels. Each access level can stipulate whether the members have
> permission to use a device from the list.
>
> I have implemented this as a checkable Model that stores the CheckState in
> the data items. This works well but doesn't allow me to have multiple,
> separate check states using the same data model. My first thought would be
> to use the QAbstractProxyModel to implement a checkable proxy so that I
> could keep a static data model with different views. Has anyone tried this?
You can't use a QAbstractProxyModel directly, since this doesn't allow you to
have additional data on your models. And from the docs: "QAbstractProxyModel
class provides a base class for proxy item models that can do sorting,
filtering or other data processing tasks." Not the proper tool here.
You have a couple of options for solving your immediate problem, and there are
issues with both of them.
1) Write a new QAbstractItemModel derived class, that uses your original data
model for the data and adds the checkable flag to each item. This is easy
enough to do, unless your underlying model changes. In that case, you have to
be very careful to match changes in your model to the new "proxy" class.
2) Don't use a QAbstractItemModel to actually store your data. Instead, you
have a datatype class that holds all your data. Instead, only use a model
derived class for viewing this particular set of check states (with otherwise
identical data in each model/view). When instantiating a new model, you tell
your datatype class to add a set of check states for this model. The biggest
issue here is that you have to code a way to get changes from the datatype
class to the models - sort of the same system the model/view classes already
have.
I would go with 2) if I were you, because it's IMHO the easiest to keep solid.
And it's actually not an uncommon pattern to use the Qt model classes to be
a "proxy" (yes, this word can have many meanings) to the real datatypes
beneath it. It doesn't always make sense to have your data stored in the
model. The SQL model is a good example of this type of system.
Bo.
--
[ signature omitted ]
Message 3 in thread
Thanks for the input Bo.
I actually did use the QAbstractProxyModel (which also inherits
QAbstractItemModel by the way) and it works really well and in a totally
transparent manner. By using it as a wrapper around any QAbstractItemModel I am
able to add a check state to any of my data models without interacting with the
underlying data. (Whether or not the data is stored in the model or externally.)
I use a dynamic data structure in the proxy to store the checkstates associated
with each index, and then sift the data(), setData(), flags() etc. methods to
intervene on the Qt::CheckStateRole, forwarding on anything I am not interested
in to the source model.
Grant
Bo Thorsen wrote:
> On mandag den 5. November 2007, Grant Carver wrote:
>> Hi
>>
>> I am implementing a list of devices that will be displayed for multiple
>> access levels. Each access level can stipulate whether the members have
>> permission to use a device from the list.
>>
>> I have implemented this as a checkable Model that stores the CheckState in
>> the data items. This works well but doesn't allow me to have multiple,
>> separate check states using the same data model. My first thought would be
>> to use the QAbstractProxyModel to implement a checkable proxy so that I
>> could keep a static data model with different views. Has anyone tried this?
>
> You can't use a QAbstractProxyModel directly, since this doesn't allow you to
> have additional data on your models. And from the docs: "QAbstractProxyModel
> class provides a base class for proxy item models that can do sorting,
> filtering or other data processing tasks." Not the proper tool here.
>
> You have a couple of options for solving your immediate problem, and there are
> issues with both of them.
>
> 1) Write a new QAbstractItemModel derived class, that uses your original data
> model for the data and adds the checkable flag to each item. This is easy
> enough to do, unless your underlying model changes. In that case, you have to
> be very careful to match changes in your model to the new "proxy" class.
>
> 2) Don't use a QAbstractItemModel to actually store your data. Instead, you
> have a datatype class that holds all your data. Instead, only use a model
> derived class for viewing this particular set of check states (with otherwise
> identical data in each model/view). When instantiating a new model, you tell
> your datatype class to add a set of check states for this model. The biggest
> issue here is that you have to code a way to get changes from the datatype
> class to the models - sort of the same system the model/view classes already
> have.
>
> I would go with 2) if I were you, because it's IMHO the easiest to keep solid.
> And it's actually not an uncommon pattern to use the Qt model classes to be
> a "proxy" (yes, this word can have many meanings) to the real datatypes
> beneath it. It doesn't always make sense to have your data stored in the
> model. The SQL model is a good example of this type of system.
>
> Bo.
>
Description: S/MIME Cryptographic Signature