Architecture Refactor Suggestion: Bigger reorganization

[Jaroslaw Staniek]

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

Depends really how one works and thinks - vertically or horizontally -
it can be dynamic.

I prefer vertical as the default.

Alternative could be handcrafted symlinks for supporting horizontal 'view'.

-- 
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