Qt4 QTreeView vs Qt3 QListView

[mcostalba]

I have finally and successfully converted a 'difficult' Qt3 multi column list to a QT4 QTreeView.

After:

- Successfully converted all the functionality of a multi column list view, included a column containing a graph, and one with a custom pixmap added to remaining normal text and with background color content dependent.

- Successfully obtained a very good loading speed, better then the super optimized and already fast Qt3 version.

- Successfully used a custom model and a custom delegate to come up with the particular data to be displayed and the custom way to do it.


I can finally say that the new QTreeView with his fellows QAbstractItemModel and QAbstractItemDelegate are... A PAIN IN THE ASS!

My humble advice is 'do not use' unless you really need. You'll be asked to add tons of cruft to make the toy start working and, at the end, you'll get something that has the same functions of the old one but with three times the code.

FWIK you get a real advantage ONLY if your application shows the same data in many different widget, and with different I mean different classes, not different objects.

I really don't understand why Qt designers choose that over engineered, academic approach.

Sorry for the rant, but I really like Qt and his API, this is the first time I hit the wall using it.

Marco

[e8johan]

There is another advantage - you can keep one data structure and then just add a model that exposes your application's internal data structures to the view of your choice.

[mcostalba]

Why you should want this if you have only one kind of view?

Your 'advantage' it's IMHO just another way (perhaps more specific) to say the same thing: if you have multple different views of the same data in your app then this new QxxxView stuff it's worth considering.

[gfunk]

Why not just use Qt4 QTreeWidget?

[mcostalba]

I need to display custom graphs on a column and some other non standard stuff on another (pixmaps among text, background content dependent coloring, etc).

And I need the list view to be very fast becuase the number of items could be high (more then 50000).


Marco


P.S: BTW did you know that on big lists QAbstractItemModel::index() is called by Qt much more then QAbstractItemModel::data(), also by a 100X factor?

So if you have a row index (say the name of the resource you need) and a cooked index (say a pointer to the resource after a name lookup) you may want to return just the name in index() and perform the costly lookup only in data().

QModelIndex MVCModel::index(int row, int column,
const QModelIndex&) const {

......
void* easyToGetPtr = getMyPointer(row, column);
return createIndex(row, column, easyToGetPtr);
}

QVariant MVCModel::data(const QModelIndex& index, int role) const {

......

QString* easyToGetPtr = static_cast<QString*>(index.internalPointer())

MyData* ptr = lookup(easyToGetPtr)); // costly lookup

.......
}


This trick can give a BIG boost to list view performance.

[dcurtis]

I hate to revive this thread but it appears to me (from looking through the code) that QTreeWidget is perfectly fine if you don't need multiple columns, it's pretty much the same as making the "tutorial" model/view and you can't share the model.

Anyone know any other reason it's a bad deal?

[dreeves]

From my perspective I think the problem for Qt people like me is that there was no compelling reason for Trolltech to "break" code like QListview. Qt4 QListView could have been made backward compatible with Qt3 QListView w/o disrupting the MVC approach used in the other classes.

Instead Qt 4 QListView is now a single column list. I have approximately a hundred thousand lines of Qt 3 code that will take months to convert to Qt 4. I anticipate that the QListView issue will be a large component of that conversion.

Also, I don't want to have to distribute the Qt3 support lib (2 meg) with all of my applications.

I'm sure that Qt 4 is a much improved product, however, IMO, Trolltech could have done a better job in mitigating source code incompatabilties.

Just my 2 cents.