Presentation for custom data types by views

elfring

I imagine that the function “setData” can be called within the implementation for a constructor of a class which was derived from QStandardItem. The provided default functionality (including support for custom data types) would be reused then.

The available view classes provide reasonable data displays for standard data types. Additional development efforts are needed (as usual) to specify desired software behaviour for custom data types when they are finally used from the referenced data model.

Which member functions should be overridden for extra data processing?
Which programming approaches would you like to recommend here?

VRonin

There's only 1 answer: a delegate.

a QStyledItemDelegate subclass is what you need. If it's only about displaying the data you just need to reimplement paint() (or displayText() if it's enough for you) and sizeHint(). The other virtual methods listed in the class docs are needed to allow users to edit the data

elfring

If it's only about displaying the data you just need to reimplement paint()

Are there any more answers (or software design constraints) to consider?
Can the amount of “painting” be reduced because specific standard functionality can be used if the complexity level will be determined from a custom data type?
(It might occasionally be sufficient to concatenate a few numbers and strings from the data which is provided by a QVariant object from the model.)

VRonin

@elfring said in Presentation for custom data types by views:

Are there any more answers (or software design constraints) to consider?

Not really, no. Unless you go into very specific obscure cases

@elfring said in Presentation for custom data types by views:

(It might occasionally be sufficient to concatenate a few numbers and strings from the data which is provided by a QVariant object from the model.

If the data is in a single role then displayText() is what you are looking for instead of reimplementing the entire paint()

elfring

Unless you go into very specific obscure cases

Another software design possibility would be to fiddle with proxies for data models (and their items), wouldn't it?