[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [Qt4-feedback] QTableView and QTableWidget performance
From:       Harri Porten <porten () froglogic ! com>
Date:       2011-12-19 20:47:56
Message-ID: alpine.DEB.2.00.1112192136140.6287 () greco ! froglogic ! com
[Download RAW message or body]

On Mon, 19 Dec 2011, Carl Schumann wrote:

> I am working on an application for which a QTableWidget or QTableView
> would be the obvious to me choice.   Unfortunately, I get sluggish
> behavior.   I took a look at KOffice's spreadsheet program, kspread.
> It also has a need for a similar user interface and its performance on
> my systems is acceptable.   When I dig into the kpsread code it appears
> they are not using the QTableWidget or QTableView for the sheets in the
> workbook, but instead using lower level Qt to manage the sheet user
> interface.
> 
> Am I correct that KOffice does not QTableWidget/View for the sheets
> UI?   Was this done for performance reasons?

The main reason is an historic one: KSpread started in KDE 1 times which 
predates the Qt 2 QTable class and particularly the Qt 4 item view 
classes. Apart from the required porting effort performance (and 
customization possibilities) might be reasons but even then, the QTable* 
classes aren't necessarily unsuitable for bigger amounts of data.

Note there is a difference between QTableWidget and QTableView. And even 
for the latter it plays a role how your model performs. Can you see the 
sluggishness with QTableView and a trivial QAbstractItemModel 
implementation that serves data in a leight-weight manner?

Harri.
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

The KOffice team has split into KOffice and Calligra suite. You find the Calligra \
project on the calligra-devel@kde.org mailing list. More information at \
www.koffice.org and www.calligra-suite.org.


[prev in list] [next in list] [prev in thread] [next in thread]