Extensions around subclassing of QStandardItem?
-
wrote on 18 Oct 2018, 19:30 last edited by
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.
-
@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.
wrote on 19 Oct 2018, 09:56 last edited by JonB@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! :)@JonB In this case it would actually make more sense to discuss with Qt devs as this is user forum :-)
-
@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.
wrote on 19 Oct 2018, 12:25 last edited byIf 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.
wrote on 19 Oct 2018, 14:22 last edited by@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
wrote on 19 Oct 2018, 17:53 last edited byhttps://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.
wrote on 1 Nov 2018, 07:48 last edited byHow do you think about the usage of customised constructor implementations for the class “QStandardItem”?