Architecture Refactor Suggestion: Bigger reorganization

[Inge Wallin]

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.