On 22 October 2012 09:30, 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 understand that this is a big task. So if we just want to solve the Karbon > filters then they should be fixed to use only the Karbon document, not the > part. But I think that this reorganization needs to be done in the long run. > >> >> 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. > > Why would a filter need painting at all? Unless it's a filter to, say, PNG. > But even so, painting is part of the document, it doesn't need a view.
That's good approach, especially the separation of painting routines from the headless part. Regarding the above hierarchy with ui/* dirs -- where would be the place for app-specific code that's not ui-related? Moreover, In mid term (3.0), following the approach of Qt 5, I wonder if we couldn't have the libs: - moved to separate repo(s) - changed to Qt-only (most easy for filters - gives hope of getting more contributors from Qt-only ecosystem). (I've been dreaming about this during the 1st Calligra sprint) -- regards / pozdrawiam, Jaroslaw Staniek Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org Qt Certified Specialist | http://qt-project.org http://www.linkedin.com/in/jstaniek _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
