Architecture Refactor Suggestion: Bigger reorganization

[Inge Wallin]

On Monday, October 22, 2012 19:49:21 Sven Langkamp wrote:
> On Mon, Oct 22, 2012 at 9:30 AM, 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 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?