[Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Bo Thorsen]

Den 13-01-2016 kl. 23:07 skrev Frank Rueter | OHUfx:
> Thanks Bo,
>
> when you say "it's bad in so many ways", are you referring to performance?
>
> I just realised that my last conversation with Jason had dropped the CC
> to the list, so here it is again :
>
>     so a few lines into the new code and I believe I'm starting to
>     realise that QAbstractTableModel is the wrong choice for me, let's
>     see if I get this right:
>
>     I need each cell to:
>
>       * store a reference to a custom object in the host application
>       * get it's background and foreground colour from the host
>         application's object
>       * determine the right delegate output based on the data type/
>         external object class
>       * drive the external object's value upon datatChanged
>       * etc.
>
>     When I got as far as implementing the background role in my
>     QAbstractTableModel's data method, the resulting view took about 4
>     seconds to resize, while scrolling left me with the ol' spinning
>     beach ball (OSX).
>     The same code utilising QStandarItemModel reacts instantaneously
>     without trouble, even with way more data.
>
>     I suppose this is because I am storing those object references in
>     each QStandarItem as I construct the data when using
>     QStandarItemModel. So later on, those values are readily available
>     within my data model.
>     When putting those references into QAbstractTableModel.data(), they
>     are constantly called upon as the view changes, causing the massive
>     slow down.
>
>     In order to keep the view fast, I need to refactor my code and
>     somehow store the custom data only once, so things like background
>     colour etc. are determined within my model's data when needed,
>     rather than having to call the host application constantly to
>     retrieve the same info.
>     Which essentially turns the table model into an item model, and I
>     might as well use the QStandardItemModel or at least
>     QAbstractItemModel to begin with.
>
>     Does that sound about right?
>
>
> Bo, reading your reply makes me feel like I should keep playing with
> QAbstractTableModel (or QAbstractItemModel) and write all the behaviour
> I need from QStandardItemModel myself?

Well, you almost already answered the question yourself. It's obvious 
your access from data() the real model is where the problem lies.

> I feel like the item based approach is handier as I can subclass a
> QStandardItem and give it a reference to the external object it
> represents, then have the data read/write from/to that.
> I don't think I get that with a table model unless I re-invent the wheel.

MyObject** references;

Can't be much faster than that.

> Any thoughts on the above?

To me QStandardItemModel is a quick hack I sometimes use when I just 
want to show a bit on the screen. But those temporary things have a 
tendency to stick around, and at some point I always end up rewriting 
the stuff with the real thing.

If you have performance issues with a QAbstractTableModel over a 
QStandardItemModel, you're doing something wrong.

I think the only place where I might use a QStandardItemModel for 
something real is if you have a static set of information that you just 
need to show. If it never changes, then it's an easy model to use.

At the DevDays in 2006 (I think) I did a presentation on the model view 
classes. I basically told everyone that QStandardItemModel is the path 
to the dark side there as well. And one of the Trolltech guys came up 
and we had an interesting discussion about it. He did argue that 
sometimes there are cases where this makes sense.

But I'm biased. I hate that class and I really like the table and list 
model classes.

Bo.

> On 13/01/16 10:27 pm, Bo Thorsen wrote:
>> Hi Frank,
>>
>> Den 12-01-2016 kl. 22:40 skrev Frank Rueter | OHUfx:
>>> I just joined this list so hello everybody.
>>> I'm using QT via PySide mainly to create tools for vfx workflows and
>>> custom tools for the software Nuke.
>>> <http://www.thefoundry.co.uk/products/nuke/>
>>> I'm not a programmer by trade, more of a vfx artist and technician using
>>> Python/PySide to enhance pipelines and workflows for myself and other
>>> companies.
>>> Currently I am writing a custom spreadsheet that will need many custom
>>> ItemDelegates and a controlled way of data input/output when a cell's
>>> data is changed.
>>> I will also need to write a feature that allows for multiple cells to be
>>> changed at the same time (haven't got that far yet though).
>>>
>>> The amount of items will potentially be in the 100,000s and a lot of
>>> filtering will be going on.
>>>
>>> I started using the QStandardItemModel and so far things are working
>>> fine, but I haven't implemented the delegates or editors yet, and I
>>> believe I will also have to override the data()/setData() methods in
>>> order to control how the data is managed on IO.
>>>
>>> I can't make up my mind if I should switch to using the
>>> QAbstractTableModel before proceeding.
>>> I am using some of the QStandardItemModel's method's, such as clear()
>>> and item() and setItem(), but I guess those are easy to re-implement.
>>>
>>> The docs say that one should consider using QAbstractTableModel (or
>>> QAbstractItemModel) for efficiency and flexibility, but I am struggling
>>> to make an educated decision because I haven't used model/views often
>>> enough yet to know about all the pros and cons, and I can't find a
>>> discussion concerning this online.
>>>
>>> I have started re-writeing the code using QAbstractTableModel, trying to
>>> get to the same level I'm at with the code using the QStandardItemModel.
>>> It seems a bit harder than I thought, but I will keep going for training
>>> purposes if nothing else, hoping that I might even have a more
>>> responsive model in the end, but I'm just not sure if it's worth it in
>>> my case, or if I should just stick to the pre-fab QStandardItemModel.
>>>
>>> Any advice from more experienced programmers on how to make that
>>> decision would be very much appreciated. I'd hate to finish writing the
>>> code only to find out that it's too slow for large data sets, and then
>>> re-jig everything to use the QAbstractTableModel.
>>
>> To me, the standard item model has always been something I use as
>> little as I can. It's bad in so many ways. But I do understand why
>> sometimes it's a quick fix for a small problem.
>>
>> Implementing a proper table model is not as easy, but in the long run
>> you will prefer it. Once a proper model is done, it just keeps
>> working. And it can handle the large load you are talking about.
>>
>> If it was me, I wouldn't have to think about this. It's a clear case
>> of a proper table model.
>>
>> Bo Thorsen,
>> Director, Viking Software.
>>
>
> --
> ohufxLogo 50x50 <http://www.ohufx.com> 	*vfx compositing
> <http://ohufx.com/index.php/vfx-compositing> | *workflow customisation
> and consulting <http://ohufx.com/index.php/vfx-customising>* *
>

Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu