<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 12/19/2011 11:52 PM, Jaroslaw Staniek wrote:
<blockquote
cite="mid:CAOj7QQ1OhHYiPw8oxVz3EOFpRM6TXJ6BapNsEbnrwVpYjzBOUQ@mail.gmail.com"
type="cite">
<pre wrap="">On 19 December 2011 21:47, Harri Porten <a class="moz-txt-link-rfc2396E" href="mailto:porten@froglogic.com"><porten@froglogic.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Mon, 19 Dec 2011, Carl Schumann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
Yes :)
Exactly the same goes to KexiTableView (for database tabular view) but
in this case the data chunks can be way bigger than in spreadsheets.
(CCd to <a class="moz-txt-link-abbreviated" href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a>)
</pre>
</blockquote>
<font size="-1"><br>
I think one of the problems lays in interview aka Qt's model/view
separation. In KSpread (or Calligra tables how it's named this
days) we have a high demand for repeating data where properties,
content, styles for a cell are shared between multiple cells. To
enable this we do not feed the view just with the data from one
model but we actually spit the data into different models (aka
storages in Tables) and each of them is able to define a region
and not only a single cell where that data should be applied to.
Those repeating-cells informations are then used in both on one
hand in the model to store and receive those informations only one
for a region and in the view to display it only once but "copy"
the display result over (not exactly the case but explaining it in
more detail would be a bit out of scope).<br>
<br>
OpenOffice.org Calc or Libreoffice Calc do very much the same.
MSOffice has a better design here in that it shares content
independent of the neighborhood where that content is located.
That means they do not define repeating regions but shared
content. In a similar way like us they also do that on a
fine-granulate base means they can share</font><font size="-1">
independently</font><font size="-1"> a formula, a number, text,
style, formatting, etc. for each cell with other cells.<br>
<br>
I think the concept of repeating or shared content is rather
essential for dealing with large amount of data and more so in the
case of spreadsheets where repeating content is more the rule then
an exception. The second more obvious thing and to my knowledge
already done by interview is to load/fetch/display/etc. only those
data that is visible.<br>
<br>
Hope that helps. Greatings from the Calligra Suite developer-team
:-)<br>
<br>
</font>
</body>
</html>