Next-gen Table View implementation for Kexi

[Jaroslaw Staniek]

Hi,
This is mostly FYI on what I brought from the Qt Dev Days in context
of Calligra/Kexi. Perhaps some of you would find it useful and also
consider some convergence between components of Active and Desktop
Calligra.

As you may know Kexi's Table View is one of the hugest widgets out
there, similar in complexity to the spreadsheet view of Sheets (minus
ODF part). At the moment the Table View still depends on Qt3Support
and removing the dependency (and thus possibly adding regressions) is
a low priority for me.

As a follow up of considerations
[http://blogs.kde.org/2011/05/31/future-kexi-table-view] I'd say it's
good development of next-gen Table View has not even started in the
meantime. Qt 5 is coming and on Dev Days I've seen current iteration
of Quick Desktop components and code-it-all-in-QML approaches for
various widgets and live coding by Jens Bache-Wiig:

https://lh3.googleusercontent.com/-on3qubSCSWs/UKVn6oozAcI/AAAAAAAAFfw/pNPJrwgnTac/s800/P1140786.JPG

(see also 'Desktop Components for QtQuick' abstract at
https://qtconference.kdab.com/node/23#Desktop_Components)

Later, Jens presented me the stuff that's explained at
[http://blog.qt.digia.com/blog/2011/05/26/table-view-with-qt-quick/]
and answered some questions (thanks!). The table view he implemented
addresses simpler needs but I came to conclusion the technology (QML)
is there and is maturing. That the idea makes sense I also confirmed
with always friendly and helpful Volker Krause from KDAB.

My current idea is that one day I'll try to go with the QML (2)
implementation, where cells have variable sizes, delegates are more
dynamic than in Model/View C++ API, and editors would use Quick
Desktop Components. In addition using QML would also easier bring the
mobile version of the view. The desktop components would work 'as
native' within KDE (including styles) sooner or later and at Qt level
alone the stable release is reportedly planned near the summer 2013,
so the "One day" means about year to me, what's like fair assumption.

Alternatives were:
- port to Qt 4 (QScrollArea with a big QPainter) and keep the code in
Calligra 3 / Qt 5; the same problems with embedding widgets and lack
of dynamic rows as in Qt 3, poor (visual) mixing of QWidget-based
editors with the canvas surface (they look out of place on a canvas,
which is bigger problem than eventual lower-nativeness of Quick
Desktop Components)

- port to Qt Graphics View - that would hit a wall because of some
bugs and disadvantages presented e.g. by current KDE4's Plasma (users
report some display glitches even under KDE 4.9); Qt Graphics View
gives no advantage for nearly infinite number of rows, even if models
are used (models in Qt APIs are at most Trees/Tables, what not fully
matches the needs of SQL models and db interaction as the story of the
discontinued QtSql module shows)


PS: Sci-fi: Kexi Forms could be also improved if QML anchors were be
used instead of Qt Layouts. The latter (especially nested) have never
been understood by end-user so Kexi hides them. This of course means
Forms in QML...

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek