[Interest] need advise on QStandardItemModel vs. QAbstractTableModel

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

Any thoughts on the above?

Thanks,
frank



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>* *

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160114/b66de594/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ohufxLogo_50x50.png
Type: image/png
Size: 2666 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160114/b66de594/attachment.png>