Architecture Refactor Suggestion: Bigger reorganization

[Inge Wallin]

On Monday, October 22, 2012 20:49:05 Sven Langkamp wrote:
> On Mon, Oct 22, 2012 at 8:08 PM, Inge Wallin <inge at lysator.liu.se> wrote:
> > On Monday, October 22, 2012 19:49:21 Sven Langkamp wrote:

...

> > > 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?
> 
> Calligra Active is a special case. It would likely sit on the the top level
> with the other applications and like to their core libraries. I think it's
> better to have one exception than completely changing all the others.

Ok, that makes sense.

> > And how would you handle Words and Author that share core functionality?
> 
> Maybe an extra folder wordprocessing and in that folder Words and Author as
> seperate uis for the wordprocessing core.

This is not so nice.  We also have the same problem with Karbon and Flow: I.e. 
they work on the same document type. I expect more of these when we get more 
applications that are fit to a specific purpose.  How about a simplified kids 
office ui, for instance?

Here is a third problem with your proposed outline: how about the current 
libs/widgets?  That would fit perfectly as ui/desktop/libs/widgets/ in my 
proposal but I don't really see where you would fit it in your app-oriented 
approach.

In general I think that we should make horizontal slices (layers in a layered 
approach) rather than vertical (i.e. app-oriented). The reason for that is 
that it is easier to find common components to put in libraries with such a 
model. I believe an app-oriented approach will be littered with special cases 
and difficult to find libraries. The disadvantage that you mention, i.e. paths 
in commits will be less specific is a minor one. If it really is important you 
could probably split it in two different commits in many cases (not all, of 
course).