Hi,
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.
Thanks,
frank
--
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