On Sunday, October 21, 2012 18:11:18 Yue Liu wrote: > 2012/10/21 Boudewijn Rempt <b...@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@kde.org > > https://mail.kde.org/mailman/listinfo/calligra-devel > > _______________________________________________ > calligra-devel mailing list > calligra-devel@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. _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
