Support for constructing QStandardItem objects from QVariant references?
-
… that takes the custom type directly, without having to do QVariant conversion:
I imagine that this another software development challenge if you need to work with the provided generic (or standard) programming interfaces.
class MyItem : public QStandardItem {
…
MyData *m_data;
};I find the specification of this member variable questionable for such a software design approach because the base class should take care of the desired data storage.
You might add attributes there for other design reasons.@elfring said in Support for constructing QStandardItem objects from QVariant references?:
… that takes the custom type directly, without having to do QVariant conversion:
I imagine that this another software development challenge if you need to work with the provided generic (or standard) programming interfaces.
Sorry, I didn't understand this. Could you rephrase it?
I find the specification of this member variable questionable for such a software design approach because the base class should take care of the desired data storage.
That's true, but you also didn't like converting/copying data in/out of QVariant. That's why I suggested this design, as a compromise to meet your different goals.
Like I mentioned before, QStandardItemModel is not well-suited for handling custom data structures. If you want a clean software design AND avoid converting/copying data, then avoid QStandardItemModel. Subclass QAbstractItemModel instead.
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
-
@elfring said in Support for constructing QStandardItem objects from QVariant references?:
… that takes the custom type directly, without having to do QVariant conversion:
I imagine that this another software development challenge if you need to work with the provided generic (or standard) programming interfaces.
Sorry, I didn't understand this. Could you rephrase it?
I find the specification of this member variable questionable for such a software design approach because the base class should take care of the desired data storage.
That's true, but you also didn't like converting/copying data in/out of QVariant. That's why I suggested this design, as a compromise to meet your different goals.
Like I mentioned before, QStandardItemModel is not well-suited for handling custom data structures. If you want a clean software design AND avoid converting/copying data, then avoid QStandardItemModel. Subclass QAbstractItemModel instead.
Could you rephrase it?
The class “QVariant” is a generic programming interface for the handling of known data structures.
That's true,
Thanks for your acknowledgement.
but you also didn't like converting/copying data in/out of QVariant.
Yes. - Thus I am looking again for useful software adjustments there.
Subclass QAbstractItemModel instead.
I would appreciate if I can reuse existing functionality from a higher level base class.
-
@elfring said in Support for constructing QStandardItem objects from QVariant references?:
… that takes the custom type directly, without having to do QVariant conversion:
I imagine that this another software development challenge if you need to work with the provided generic (or standard) programming interfaces.
Sorry, I didn't understand this. Could you rephrase it?
I find the specification of this member variable questionable for such a software design approach because the base class should take care of the desired data storage.
That's true, but you also didn't like converting/copying data in/out of QVariant. That's why I suggested this design, as a compromise to meet your different goals.
Like I mentioned before, QStandardItemModel is not well-suited for handling custom data structures. If you want a clean software design AND avoid converting/copying data, then avoid QStandardItemModel. Subclass QAbstractItemModel instead.
@JKSH said in Support for constructing QStandardItem objects from QVariant references?:
QStandardItemModel is not well-suited for handling custom data structures.
I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes
@elfring said in Support for constructing QStandardItem objects from QVariant references?:
I would appreciate if I can reuse existing functionality from a higher level base class.
Since we are moving one step higher, why not be even more generic:
QAbstractItemModel* model = new QStandardItemModel(parent);This allows you to:
- use
QStandardItemModelinstead of subclassing your own - use your custom data types seamlessly as
QAbstractItemModelalways usesQVariant - Lets you abstract the implementation of the model by using the API that is guaranteed to be available in every model
"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
- use
-
@JKSH said in Support for constructing QStandardItem objects from QVariant references?:
QStandardItemModel is not well-suited for handling custom data structures.
I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes
@elfring said in Support for constructing QStandardItem objects from QVariant references?:
I would appreciate if I can reuse existing functionality from a higher level base class.
Since we are moving one step higher, why not be even more generic:
QAbstractItemModel* model = new QStandardItemModel(parent);This allows you to:
- use
QStandardItemModelinstead of subclassing your own - use your custom data types seamlessly as
QAbstractItemModelalways usesQVariant - Lets you abstract the implementation of the model by using the API that is guaranteed to be available in every model
It is not performance-efficient
Will this information trigger any further software evolution?
but it is generic enough to handle all kinds of custom metatypes
This design aspect is reasonably documented.
Since we are moving one step higher, why not be even more generic:
QAbstractItemModel* model = new QStandardItemModel(parent);This data structure combines standard (or also custom) items.
use QStandardItemModel instead of subclassing your own
A derivation from an item class is needed if you would like to add member functions there.
It is a matter how the desired software behaviour is assigned to specific items or corresponding models overall. - use
-
It is not performance-efficient
Will this information trigger any further software evolution?
but it is generic enough to handle all kinds of custom metatypes
This design aspect is reasonably documented.
Since we are moving one step higher, why not be even more generic:
QAbstractItemModel* model = new QStandardItemModel(parent);This data structure combines standard (or also custom) items.
use QStandardItemModel instead of subclassing your own
A derivation from an item class is needed if you would like to add member functions there.
It is a matter how the desired software behaviour is assigned to specific items or corresponding models overall.@elfring said in Support for constructing QStandardItem objects from QVariant references?:
It is not performance-efficient
Will this information trigger any further software evolution?
No. Because... (see below)
I would appreciate if I can reuse existing functionality from a higher level base class.
...remember, engineering involves finding the right balance. In general, these are the trade-offs when you choose a high-level API:
- Pros:
- Simple, easy to use
- More protections against errors
- Cons:
- Less performant
- Less flexible
When you choose the pros of the high-level QStandardItemModel, you also choose the cons.
- Pros:
-
@JKSH said in Support for constructing QStandardItem objects from QVariant references?:
QStandardItemModel is not well-suited for handling custom data structures.
I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes
@elfring said in Support for constructing QStandardItem objects from QVariant references?:
I would appreciate if I can reuse existing functionality from a higher level base class.
Since we are moving one step higher, why not be even more generic:
QAbstractItemModel* model = new QStandardItemModel(parent);This allows you to:
- use
QStandardItemModelinstead of subclassing your own - use your custom data types seamlessly as
QAbstractItemModelalways usesQVariant - Lets you abstract the implementation of the model by using the API that is guaranteed to be available in every model
@VRonin said in Support for constructing QStandardItem objects from QVariant references?:
@JKSH said in Support for constructing QStandardItem objects from QVariant references?:
QStandardItemModel is not well-suited for handling custom data structures.
I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes
I agree that it's generic enough to handle custom types. I just don't think it handles them nicely. (And to clarify, I was talking about custom, multi-element data structures that can't be easily represented by 1 string.)
My main gripe is this: 1 Item represents 1 "cell" in the View, and by default each cell only shows 1 "element". Thus, if I were to squeeze a complex multi-element data structure into an Item, then I'd need to write a custom Delegate too.
But anyway, this is a matter of personal preference. There's still a place for QStandardItemModel and I'm still happy to help someone use it if they want to.
Since we are moving one step higher, why not be even more generic:
I believe that's going lower-level, not higher-level... right...?
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
- use
-
@elfring said in Support for constructing QStandardItem objects from QVariant references?:
It is not performance-efficient
Will this information trigger any further software evolution?
No. Because... (see below)
I would appreciate if I can reuse existing functionality from a higher level base class.
...remember, engineering involves finding the right balance. In general, these are the trade-offs when you choose a high-level API:
- Pros:
- Simple, easy to use
- More protections against errors
- Cons:
- Less performant
- Less flexible
When you choose the pros of the high-level QStandardItemModel, you also choose the cons.
- Pros:
-
@VRonin said in Support for constructing QStandardItem objects from QVariant references?:
@JKSH said in Support for constructing QStandardItem objects from QVariant references?:
QStandardItemModel is not well-suited for handling custom data structures.
I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes
I agree that it's generic enough to handle custom types. I just don't think it handles them nicely. (And to clarify, I was talking about custom, multi-element data structures that can't be easily represented by 1 string.)
My main gripe is this: 1 Item represents 1 "cell" in the View, and by default each cell only shows 1 "element". Thus, if I were to squeeze a complex multi-element data structure into an Item, then I'd need to write a custom Delegate too.
But anyway, this is a matter of personal preference. There's still a place for QStandardItemModel and I'm still happy to help someone use it if they want to.
Since we are moving one step higher, why not be even more generic:
I believe that's going lower-level, not higher-level... right...?
@JKSH said in Support for constructing QStandardItem objects from QVariant references?:
then I'd need to write a custom Delegate too.
100% agree on this point
I believe that's going lower-level, not higher-level
I meant higher level of abstraction (i.e. just look at the interface, not the implementation)
I would prefer to adjust the remaining development challenges somehow in this area.
Then a custom model is the way to go but it is not easy for people approaching Qt for the first time.
P.S.
It might be just a language issue but this is not StackOverflow, you won't get shouted at if you don't use exact technical terminology all the time, you can relax"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
@JKSH said in Support for constructing QStandardItem objects from QVariant references?:
then I'd need to write a custom Delegate too.
100% agree on this point
I believe that's going lower-level, not higher-level
I meant higher level of abstraction (i.e. just look at the interface, not the implementation)
I would prefer to adjust the remaining development challenges somehow in this area.
Then a custom model is the way to go but it is not easy for people approaching Qt for the first time.
P.S.
It might be just a language issue but this is not StackOverflow, you won't get shouted at if you don't use exact technical terminology all the time, you can relax@VRonin said in Support for constructing QStandardItem objects from QVariant references?:
It might be just a language issue but this is not StackOverflow, you won't get shouted at if you don't use exact technical terminology all the time, you can relax
+1 for pointing out that this forum is not like The Gestapo from SO!
-
Could you rephrase it?
The class “QVariant” is a generic programming interface for the handling of known data structures.
That's true,
Thanks for your acknowledgement.
but you also didn't like converting/copying data in/out of QVariant.
Yes. - Thus I am looking again for useful software adjustments there.
Subclass QAbstractItemModel instead.
I would appreciate if I can reuse existing functionality from a higher level base class.
@elfring said in Support for constructing QStandardItem objects from QVariant references?:
I would appreciate if I can reuse existing functionality from a higher level base class.
Sorry! I just re-read this line and realized you said "higher level base class". In this case, please ignore what I said about choosing pros and cons.
