Support for constructing QStandardItem objects from QVariant references?

elfring

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.

JKSH

@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.

JKSH

@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...?

elfring

…, you also choose the cons.

I would prefer to adjust the remaining development challenges somehow in this area.

VRonin

@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

JonB

@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!

JKSH

@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.