Extensions around subclassing of QStandardItem?
-
Subclassing is described for the class “QStandardItem” to some degree.
I have got the impression that this programming interface expects to manage data completely on its own so far. The current storage implementation can be seen in the class “QStandardItemPrivate”.
I imagine that it would be useful if the involved dependencies and constraints can be determined also by customised queries on databases.
How do you think about a different mapping between these data processing approaches? -
Subclassing is described for the class “QStandardItem” to some degree.
I have got the impression that this programming interface expects to manage data completely on its own so far. The current storage implementation can be seen in the class “QStandardItemPrivate”.
I imagine that it would be useful if the involved dependencies and constraints can be determined also by customised queries on databases.
How do you think about a different mapping between these data processing approaches?@elfring said in Extensions around subclassing of QStandardItem?:
I imagine that it would be useful if the involved dependencies and constraints can be determined also by customised queries on databases.
How do you think about a different mapping between these data processing approaches?about what exactly are you talking about? o.O
Am i assuming right that you want to configure how QStandardItem/QStandardItemModel works via a database?!
If so no chance. Thats way out of the scope of standard item models to quickly setup common item view use cases.Nevertheless since QStandardItemModel is based upon QAbstractItemModel you are free to implement a custom model specifically to your needs. Which honestly isn't that complicated in the end.
--- SUPPORT REQUESTS VIA CHAT WILL BE IGNORED ---
If you have a question please use the forum so others can benefit from the solution in the future -
@elfring said in Extensions around subclassing of QStandardItem?:
I imagine that it would be useful if the involved dependencies and constraints can be determined also by customised queries on databases.
How do you think about a different mapping between these data processing approaches?about what exactly are you talking about? o.O
Am i assuming right that you want to configure how QStandardItem/QStandardItemModel works via a database?!
If so no chance. Thats way out of the scope of standard item models to quickly setup common item view use cases.Nevertheless since QStandardItemModel is based upon QAbstractItemModel you are free to implement a custom model specifically to your needs. Which honestly isn't that complicated in the end.
@raven-worx
If you read the OP's posts on this subject & others elsewhere, I think you'll actually discover he wishes to have a discussion on theoretical approaches to coding and how Qt implements them, rather than anything to code/solve specifically! :) -
@raven-worx
If you read the OP's posts on this subject & others elsewhere, I think you'll actually discover he wishes to have a discussion on theoretical approaches to coding and how Qt implements them, rather than anything to code/solve specifically! :) -
@elfring said in Extensions around subclassing of QStandardItem?:
I imagine that it would be useful if the involved dependencies and constraints can be determined also by customised queries on databases.
How do you think about a different mapping between these data processing approaches?about what exactly are you talking about? o.O
Am i assuming right that you want to configure how QStandardItem/QStandardItemModel works via a database?!
If so no chance. Thats way out of the scope of standard item models to quickly setup common item view use cases.Nevertheless since QStandardItemModel is based upon QAbstractItemModel you are free to implement a custom model specifically to your needs. Which honestly isn't that complicated in the end.
If so no chance.
I see a chance in passing a customised “QStandardItemPrivate” object to a protected constructor for achieving more direct database accesses.
Which honestly isn't that complicated in the end.
There are specific software development challenges to consider because these data models tend to collaborate with QStandardItem objects in some ways.
-
If so no chance.
I see a chance in passing a customised “QStandardItemPrivate” object to a protected constructor for achieving more direct database accesses.
Which honestly isn't that complicated in the end.
There are specific software development challenges to consider because these data models tend to collaborate with QStandardItem objects in some ways.
@elfring said in Extensions around subclassing of QStandardItem?:
I see a chance in passing a customised “QStandardItemPrivate” object to a protected constructor
https://wiki.qt.io/D-Pointer#Inheriting_d-pointers_for_optimization
-
@elfring said in Extensions around subclassing of QStandardItem?:
I see a chance in passing a customised “QStandardItemPrivate” object to a protected constructor
https://wiki.qt.io/D-Pointer#Inheriting_d-pointers_for_optimization
https://wiki.qt.io/D-Pointer#Inheriting_d-pointers_for_optimization
Thanks for this link to useful information.
But I read the declaration of QStandardItemPrivate class in the way that no virtual functions are provided. So it seems that derivation is not supported for such a class so far.
Would you become interested to improve the software situation for database accesses here anyhow? -
@elfring said in Extensions around subclassing of QStandardItem?:
I imagine that it would be useful if the involved dependencies and constraints can be determined also by customised queries on databases.
How do you think about a different mapping between these data processing approaches?about what exactly are you talking about? o.O
Am i assuming right that you want to configure how QStandardItem/QStandardItemModel works via a database?!
If so no chance. Thats way out of the scope of standard item models to quickly setup common item view use cases.Nevertheless since QStandardItemModel is based upon QAbstractItemModel you are free to implement a custom model specifically to your needs. Which honestly isn't that complicated in the end.
How do you think about the usage of customised constructor implementations for the class “QStandardItem”?
