The future of Calligra Active

[Shantanu Tushar Jha]

On Thu, Mar 14, 2013 at 12:47 AM, Thomas Pfeiffer <colomar at autistici.org>wrote:

> On Thursday 14 March 2013 00:26:28 Shantanu Tushar Jha wrote:
> > Hi,
> >
> > During the Calligra sprint last week, we were discussing over Calligra
> > Active's future. One good thing that came along is that we started work
> on
> > creating reusable Calligra QML components that can be used in isolation
> to
> > render documents, and perform basic viewing operations. This will help in
> > creating Calligra touch UIs for Sailfish etc. Work on this has started
> and
> > we already have the component for Text Documents :)
>
> Great! So it's a bit like a QML equivalent to kparts (not code-wise, but
> the
> way they can be used)?
>

Yes, kind of. Basically all you need to get an application to show a
textdocument, be able to search it, and show page thumbs, all you gotta do
is this-

import QtQuick 1.1
import org.calligra.CalligraComponents 0.1 as Calligra

Item {
    width: 100
    height: 200

    Calligra.TextDocumentCanvas {
        id: canvas
        source: "document.odt"
        anchors.fill: parent
        zoomMode: Calligra.TextDocumentCanvas.ZOOM_WIDTH

        MouseArea {
            anchors.fill: parent
            onClicked: parent.searchTerm = 'text'
        }

        ListView {
            id: pageThumbnails
            anchors.centerIn: parent
            model: canvas.documentModel
            delegate: Image { source: decoration }
        }
    }
}

Sweet, isn't it? :D


> > Another question that came up (follow-up of [1]) was whether Calligra
> > Active should remain as a single application to handle every document
> type,
> > or do we want to have a Active version for each corresponding Desktop
> app.
> > The main reason this was an idea is because going by PA's workflow, when
> we
> > would like to create documents we just need to fire the text document
> > editing program and it would do its job. A technical motivation behind
> > doing that is the difference in the way text docs, spreadsheets,
> > presentations are handled in code. For example, text docs are limited in
> > size, scroll vertically; spreadsheets are virtually unlimited and scroll
> in
> > both directions; while slideshows don't really "scroll", we switch
> slides.
> > Due to this handling of special cases, the code is also kind of complex
> and
> > breaking it into independent bits might help. There are other factors
> like
> > the way we handle mimetypes etc.
> >
> > These were the points what we discussed about whether or not to split,
> but
> > in the end, its very important to know if this makes sense from PA's
> > perspective, especially usability.
> >
> > CA should stay as it is right now? Or have separate apps? Thoughts?
>
> As already expressed on the Calligra mailing list, from my perspective it
> makes sense to split the applications up. Of course UIs should be
> consistent
> wherever it makes sense, but this should be ensured by HIGs, not by a
> common
> UI being forced onto different usage patterns. Reading a text document
> simply
> isn't the same thing as doing a presentation, so they cannot have identical
> UIs.
> Other than that, with the task-centric paradigm, users should not notice
> whether they're using different applications or not anyways. As you already
> mentioned, we don't want users to ever start "Calligra Active", but instead
> "Create a Presentation" or "Open letter XYZ". Therefore there shouldn't be
> a
> central "Home Screen" for CA anyway, and thus there would be no advantage
> from
> the user's perspective in cramming it all into one application.
>
> So splitting is good, we want UIs to be as modular as possible so that they
> can be weaved together to create workflow tools.
>
> Cheers,
> Thomas
>

I'll take that as a +1, anyone else having different views? We need to be
sure before we do such a refactoring ;)

-- 
Shantanu Tushar    (UTC +0530)
http://www.shantanutushar.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20130314/d80235a7/attachment.html>