Branding Calligra's QML UI as Calligra Active

[Jaroslaw Staniek]

On 21 April 2011 15:23, Shantanu Tushar Jha <jhahoneyk at gmail.com> wrote:
> Hi Jaroslaw,
>
> On Thu, Apr 21, 2011 at 3:24 PM, Jaroslaw Staniek <staniek at kde.org> wrote:
>>
>> On 21 April 2011 09:35, Cyrille Berger Skott <cberger at cberger.net> wrote:
>> > On Thursday 21 April 2011, Shantanu Tushar Jha wrote:
>> >> Right now my code is not that modular, and I plan to do that once I
>> >> understand how to properly use Calligra libs.
>> >> Once that is done, we can have different UIs for different form
>> >> factors.
>> >> But anyway, even if we have a mobile version for now,
>> >> for Active, its better than nothing.
>> > Not being strictly modular now is fine :) Especially since your project
>> > is
>> > exploratory, and after all, the "calligra/active/lib" can start by being
>> > empty
>> > (or contains only koabstraction library), and then when there is more
>> > common
>> > code it get moves from the mobile subdirectory to the relevant library.
>>
>> Some notes:
>> If I undestand correctly, neither 'Mobile' code for calligra is
>> conceptually subset of Active nor the other way round.
>>
>> Where's KoAbstraction in this?
>> KoAbstraction (or however it will be named) shall contain parts that
>> are dependencies of some Calligra apps; apps that are willing to
>> interact with other Calligra apps, e.g. Words<->Tables bridge. This is
>> second purpose of KoAbstraction, I discussed with Inge in Berlin
>> (let's not go too off-topic though). The first is a tool for creating
>> custom office apps 'in minutes'. So KoAbstraction is part of desktop
>> too.
>
> So to be clear, can the QML UI be built using KoAbstraction? The reason is
> that I am already copying a lot of code from it, given that KoAbstraction
> only helps to create QWidget based UIs (correct me if I am wrong).

Shantanu,
One thing KoAbstraction does is abstracting (hmm..)  typical
features/actions of applications (actually document based main apps:
Words, Tables, Stage). This is the 'controller' part, actually known
as KoAbstractApplicationController. Example actions that you use when
implementing core workflow is: concept of the current document, it's
opening process (should be asynchronous), standard action like
formatting (in progress now), querying support for document types,
information about document (page count, current page), navigation (go
to slide/page...).

All this is GU Itoolkit-independent (with exceptions that we can actively fix).

Another abstracted area is the GUI abstraction. This is GUI
toolkit-dependent as in the case of WebKit. For now the only complete
implementation of Calligra is for QWidget world so KoAbstraction is
for QWidget too. I am confident that while QML GUI is developed, the
abstraction can be further extended to address specific needs. In fact
KoAbstraction grows out of real effort of application development,
namely FreOffice, and thanks to support of FreOffice developers (and
their patience!). It could be similar case with the current effort,
QML GUI. So jsut don't be afraid to first have your concepts in your
private code, don't be afraid of copy/pasting and templorary code _as
long_ as you mark dirty areas with //! @todo marks so we can refactor
dynamically. It all looks like iterative process. "Premature
refactorization is a source of frustration ;)"

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
 KDE Software Development Platform on MS Windows (windows.kde.org)