Problems with Calligra Active and mimetypes (was: Re: Review Request 108996: update calligraactive.desktop: sync mimetypes with those of Sheets, Stage, Words, remove outdated entries)

[Friedrich W. H. Kossebau]

Hi Shantanu & all,

Am Sonntag, 17. Februar 2013, 17:45:08 schrieb Shantanu Tushar:
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108996/#review27591
> -----------------------------------------------------------
> 
> Ship it!
> 
> 
> Good catch and a nice coincidence, I was demo'ing PA to some folks here at
> gnunify.in and noticed that sometimes documents aren't really being opened
> using CA. Guess this should fix it :) Ok to backport.


Sadly did not fix it (completely).

While experimenting with the packaging of CalligraActive on 
build.pub.meego.com for PlasmaActive I found that inside CalligraActive code 
the mimetypes are hardcoded a second time, in the overloads of 
CAAbstractDocumentHandler::supportedMimetypes().
This seems needed, because Calligra Active as a single app supports three 
kinds of documents, so first has to check by the mimetypes which of the three 
document kind handler has to be used.

For PlasmaActive packaging I have chosen to just fix the problem with a patch 
that also adapts these hardcoded mimetypes, syncing them with what is in the 
desktop file, because in the packaging I know which (import) filters are 
built. Possibly will just propose to use that in the official code for now as 
well, should do no harm (as the entries in the desktop file do no harm). Is 
just not perfect.

But in the long run I would propose to change Calligra Active. And split it 
into several apps, one per document type, like it is done for the 
"desktop"/old-style-QWidget apps. The name CalligraActive is misleading 
anyway, because it has no equivalent support to Braindump, Kexi, Krita, 
Karbon/Flow and Plan.

Especially with the document-centric design of Calligra Active, where document 
editors/viewer apps should not have own filedialogs to select a file, but 
instead are always loaded with a file as parameter, it does not make so much 
sense to have one app which can handle lots of different document types and 
always on start first has to find out which internal component it should 
activate.

Then there is another problem, but that is also already existing with the 
"desktop"/old-style-QWidget apps:
the mimetypes listed in the desktop file of an program depend on the actually 
installed filters (perhaps even filter chains). Currently they are hardcoded 
to a given set in the central desktop file of an app, even if the needed 
filters might not be built and installed.

Okular devs found a workaround for this, by just installing a separate desktop 
file per supported mimetype. You can see this workaround also used in the 
Calligra sources, by the ODP plugin for Okular. So each import filter would 
need to get a separate desktop file, only installed together with the filter. 
And the central desktop file of an app would just list the buil-in native 
mimetype it supports.
Import by filter chains could be ignored for now, as I think no mimetype is 
listed in those entries which relies on a filter chain.

Means import filters would need to install their desktop file for Calligra 
Active and/or the respective "desktop"/old-style-QWidget app. Yes, complicated 
:) Calls for some buildsystem automation.

Cheers
Friedrich