Architecture Refactor Suggestion: App-irrelevent Format Filters
Inge Wallin
inge at lysator.liu.se
Tue Oct 23 08:57:00 BST 2012
On Sunday, October 21, 2012 18:11:18 Yue Liu wrote:
> 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
>
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
Yue, it seems that your filter thread got a bit hijacked -- or at least
expanded. Sorry for that.
Is there anything we can do about this filter problem for Flow in the short
term? I guess that using the Karbon core is not bad in itself. Or should the
Karbon core be extracted into a kind of vector document core in libs/ ? That
way the Flow filter will not be dependent on another application but instead
"just" of a library.
More information about the calligra-devel
mailing list