[Interest] need advise on QStandardItemModel vs. QAbstractTableModel
Frank Rueter | OHUfx
frank at ohufx.com
Thu Jan 14 01:10:40 CET 2016
Thanks Bo,
I made some progress with QStandardItemModel, an d will try to pull even
with the QAbstractTable model approach, hopefully that will help getting
a feeling for it all.
>>If you have performance issues with a QAbstractTableModel over a
QStandardItemModel, you're doing something >>wrong.
In my case I definitely did by putting all the calls to the external
objects int' the data() method. I will rework this to prepare all that
up front and make the required data accessible to data().
Cheers,
frank
On 14/01/16 11:46 am, Bo Thorsen wrote:
>
>
> 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.
>
--
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/8921c496/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/8921c496/attachment.png>
More information about the Interest
mailing list