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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
