On Monday, October 22, 2012 19:49:21 Sven Langkamp wrote: > On Mon, Oct 22, 2012 at 9:30 AM, Inge Wallin <i...@lysator.liu.se> wrote: > > 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. > > > > I think we need to make a bigger reorganization. There are two things > > that are > > currently a problem: > > > > 1. The applications themselves have more than one UI, e.g. Calligra > > Words/Sheets/Stage and Calligra Active. > > > > 2. Filters sometimes use application internals as the data model. > > > > So I suggest the following overall architecture: > > > > calligra > > > > core > > > > libs > > words > > sheets > > stage > > ... > > > > ui (or view) > > > > suite (or desktop) > > > > libs > > words > > sheets > > .... > > > > active > > ... > > > > filters > > > > libs > > xxx2yyy > > yyy2zzz > > ... > > > > tools > > > > ... > > > > In the core/ directory the parts of the applications that are UI > > independent > > should reside. It should be basically loading, storage, saving (i.e. the > > document), painting, an API for data manipulation and all commands. > > > > All views under ui/ will of course link to core/*. The filters should be > > allowed to link to core/* for loading, storage model or saving. > > I would prefer to have it at > > app/ > core/ > uidesktop/ > uiactive/ > > The reason behind is that it's much better to keep everything in a single > folder. For example if I commit somthing in krita/image and krita/ui, the > commit message shows it as krita/, with the new structure it would show > calligra/. Considering how many problems the distributions have with a > seperate filter folder, I think it's better to keep it together.
While I see your point, how would you handle calligra active that has one interface for three applications at once? And how would you handle Words and Author that share core functionality? _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
