Op 27/11/2015 om 15:01 schreef Andrej Kacian:
On Fri, 27 Nov 2015 10:39:19 +0100
André Somers <an...@familiesomers.nl> wrote:
Or is there a better way to do what I described?
Perhaps, depending on what you really want to achieve. Instantiating
QObjects everywhere is quite expensive. If you have a lot of items in
your tree, it may cause performance issues.
Hm, performance is a good point, I did not think of that.
Basically, until now I have subclassed QTreeWidgetItem just to overload
its operator<(), because I need custom sorting in this particular tree
widget.
In the Qt::UserRole column, I hold a pointer to an object, and I need
to update displayed columns when this object changes.
At the moment, I am handling this via a custom slot on QTreeWidget
(the objects emit a signal when they change), which looks up the correct
item to update and updates its columns. It works fine, but I thought
that it would be more elegant to have each item "listen" for changes in
its object directly. Hence the idea to add the QObject inheritance to my
QTreeWidgetItem subclass.
Would it not be worth consideration to move to a custom model instead
then? The custom model could just access the real items directly as well
as listen for relevant changes to notify the views via the proper API
for that.
How best to implement that depends on the actual structure of the data
you already have in your application of course, and on the kinds of
operations you need to support (it makes a difference if the tree
structure is static or may change, for instance).
However, note that getting tree models right is not trivial. Still, it
is usually the best solution. I am not a big fan of the "standard"
models, let alone the *Widget variants.
André
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
