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>* *
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
