On Monday, October 22, 2012 20:49:05 Sven Langkamp wrote: > On Mon, Oct 22, 2012 at 8:08 PM, Inge Wallin <i...@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). _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
