Branding Calligra's QML UI as Calligra Active

[Jaroslaw Staniek]

On 21 April 2011 14:21, Inge Wallin <inge at lysator.liu.se> wrote:
> On Thursday, April 21, 2011 09:35:37 Cyrille Berger Skott 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.
>
> I agree with Cyrille, and think that his suggestions a few mails back in the
> thread make a lot of sense.  Especially this:
>
> calligra/active/lib
> calligra/active/mobile   (or perhaps handset since tablets are also mobile)
> calligra/active/tablet
> calligra/active/...
>
> I also talked a lot with Aaron, and the 'Active' brand is not tied to plasma.
> It's supposed to be a whole new infrastructure complete with a HIG and Qt
> Quick components for creating applications and also a set of base applications
> (among them Calligra, hopefully).  So I think that Calligra Active will share
> a lot of code with the other Ui's like for Android, but it would *not* be the
> same since there are different look&feels between the Active HIG and the
> Android HIG. Active is also going to be initially a new UX on top of MeeGo,
> since MeeGo allows that, so it's going to be on the same level as, say, the
> MeeGo tablet UX rather than MeeGo itself.
>
> Regarding koabstraction, I talked a bit with Jaroslaw at the sprint and I
> think that I finally understand what koabstraction is about: It's a facade (á
> la the Facade Design Pattern) in front of the applications to let somebody
> manipulate documents without knowing the underlying implementation.
> Jaroslaw mentions, it may also have other uses, like bridging between apps
> even if that is not there yet (or is it?).

To be strict, it's for exposing editor/viewer-related actions for
manipulating the opened documents rather than manipulating the
document itself. For the latter task koodf and related libraries can
be employed (possible with facades, again), but this it rather a story
for different part of the Calligra Engine.

I explain then editor/viewer-related features of koabstraction (with
Controller being the central concept) more in my other post to
Shantanu. This feature set is both useful as:
#1. a building block for creating new apps
#2. as for creating bridges between different Calligra apps without
using intermediate saving to ODF or any other format.

Regarding 2., KoAbstraction as a bridge between applications is just
not used now, as cooperation between applications are more demanding
regarding the feature set.

> Thus, I think it should definitely not be in active/lib.  Rather under
> interfaces/ and perhaps with another name.  Koabstraction is a bit too general
> as a name and doesn't really tell anything.  Hence my and other people's
> confusion on what it really is. I can't really come up with a good name right
> now, but I think we should.

Yes, In Berlin we mentioned something like Calligra Application
Abstraction for #1 and #2.

2c:
Building blocks that could allow to implement a simple QMainWindow or
QML-based app in one evening could be something like Calligra
Application Templates, since the developer uses the templates and
alters them for her needs. I see the 'advertised' Qt Designer
plugin/QML component for Calligra-document view among these templates
as well.

-- 
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)