KDE architecture diagram

[Aaron J. Seigo]

On Friday, June 8, 2012 13:47:18 Aurélien Gâteau wrote:
> My goal with this diagram was to illustrate end-user products and how they
> are grouped under umbrella terms, rather than teams. 

then it isn't an architecture diagram, and it shouldn't include things like 
kdelibs.

how products are presented to the public and how the architecture is designed 
is not a 1:1 relationship. at least not in Plasma, and that is 100% 
purposeful.

> It makes total sense
> to me that Plasma developers are responsible for libplasma from kdelibs,
> Plasma components in kde-runtime, plasma-desktop, plasma-netbook from
> kde-workspace

indeed. and the architecture is such that those shared components are shared 
and there is not a huge delta between desktop, netbook and workspace.

another fun tidbit: did you know that the search & launch (aka SAL) 
containment was designed for Netbook, but is also used for the Plasma KPart 
now and is very popular amongst Desktop users? :)

> and, I guess, the Active UI part of applications like Okular
> and Marble (at least to bootstrap the process of having Active-friendly
> applications)

we are not responsible for Marble's Active UI at all. we invited Marble to get 
involved and they have. we are also not responsible for Kontact Touch or 
Calligra Active. we are big supporters of them and do help as we can, but then 
many of us do that in general because that's what we do in KDE :)

we contributed the Okular UI to Okular itself, and we hope that in future more 
of the apps will have touch UIs maintained by their respective teams in future 
because this does not scale for us. we're doing it now because we have to.

that said, this is a team structure issue, not an architecture or even a 
product issue.

btw... every time someone says "I guess..." and then instead of asking a 
question makes a statement of "fact" a kitten dies a horrible, horrible death.

please, stop guessing and start asking. we'll save a lot of pain that way.

> > Food for thought: How many Linux kernel developers do you know that try to
> > divide the Linux kernel in subprojects for servers, desktops, embedded
> > systems?
> 
> This comparison is not adapted IMO: the kernel is one single product, with
> many modules. Your comparison would work if we were shipping only one shell
> with many applets.

plasma is a single product with many modules. that's one of the core design 
concepts.

we ship one set of applets (with a few specific to different shells), share code 
between shells (libplasmagenericshell's name is a good hint there :).

this is not completely unlike the various arch/ implementations found in the 
kernel source tree.

so it is a very accurate comparison. it is a comparison that drove the design 
of plasma, so that's unsurprising.

perhaps instead of the comparison being not adapted, your understanding is 
incorrect. perhaps we offered that comparison to help improve your 
understanding. instead of arguing for your understanding to the people who 
actually designed and wrote the code in question, you could consider the 
comparison made and think about how that may require adjustment in your 
understanding.

> And actually, the kernel is very much based on subprojects: you won't find a
> lot of filesystem developers working on usb support or network-stack
> developers debugging the arm device-tree mess.

and it's exactly the same in plasma. lots of people work only on specific 
things. we have one guy who only works on folderview bugs and performance, for 
instance.

it's still one whole project from which products are derived based on the 
modules used and the build configuration.

let's try this:

Linux is an OS kernel technology from which products are derived based on the 
modules used, which are worked on by various people in sub-projects with sharp 
focus, and the build configuration selected.

Plasma is a UX technology from which products are derived based on the modules 
used, which are worked on by various people in sub-projects with sharp focus, 
and the build configuration selected.

both are accurate high-level overviews of the respective projects.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120608/6d65ef63/attachment.sig>