Architecture Refactor Suggestion: Bigger reorganization

[Jaroslaw Staniek]

On 22 October 2012 09:30, Inge Wallin <inge at lysator.liu.se> wrote:
> 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.
>
> 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