Architecture Refactor Suggestion: App-irrelevent Format Filters

[Yue Liu]

2012/10/21 Boudewijn Rempt <boud at valdyas.org>:
> On Sunday 21 October 2012 Oct, Yue Liu wrote:
>> Hi,
>>
>> Currently filters are loaded based on application's native mime-type.
>> And now we have multiple applications with same native format, such as
>> Karbon and Flow, Words and Authors. Applications with same native
>> format should have same set of format filters, but format filter codes
>> are sorted under application categories.
>>
>> So I suggest change it from current structure
>>
>> filters/xxx_app/[im,ex]port/xxx_filter
>
> It's even messier in some places, where the odf2html filter is embedded in the epub filter.
>
>>
>> to
>>
>> filters/xxx2xxx
>
> I wouldn't mind that change, but then, for Krita, we moved all the filters to the Krita folter anyway.
>
>>
>> And tell distributions package filters as one component, not with
>> apps, to avoid conflicts between same-format apps. At least Arch and
>> Chakra is already doing it this way.
>
> Fedora also did/does that already, which meant lots of bug reports since people only installed the app, not the filter component and then complained that they couldn't even open a simple jpeg in Krita!
>
> There's a complication here with the Tables filters: some of them link directly to Tables and actually don't go though an ODS intermediate. Those probably should be moved to the tables folder itself.

We can keep the dependency on App and involve new mime-types for those
filters. Just like Friedrich suggested before:
http://mail.kde.org/pipermail/calligra-devel/2012-May/005041.html

For example, if karbon filter depends on KarbonPart, we can make a
mime-type calligra/karbon.document and use it in the filter, so Flow
won't load this filter since karon.document is not supported by Flow.

And we can place the codes of this kind of app-dependent filters under
app/filters/xxx2xxx, and place those general filters under
filters/xxx2xxx, when packaging, app-dependent filters are packaged
with apps, general filters are packaged as a single package and every
app depends on it.

>
>>
>> Note: this is a problem for some Karbon filters, since they used
>> KarbonPart to access shapes for shape painting. We can modify
>> KoDocument::paintContent(painter, rect) to do that instead.
>>
>
> Ah, so Karbon has the same problem already, too.
>
>
> --
> Boudewijn Rempt
> http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel