KDE architecture diagram

[Aurélien Gâteau]

Le vendredi 8 juin 2012 12:01:39 Sebastian Kügler a écrit :
> On Thursday, June 07, 2012 22:16:13 Aurélien Gâteau wrote:
> > Le jeudi 7 juin 2012 21:11:09 Aaron J. Seigo a écrit :
> > > there's an artificial spliting between "kde workspace" and "plasma
> > > active"
> > > that does not exist. those of us working on these things keep saying
> > > that
> > > but nobody seems to either be listening to or believing us :)
> > 
> > If I am not mistaken, kde workspace and plasma active are developed in
> > different repositories, have different release schedules and target
> > different devices. That was enough for me to split them.
> 
> Most of it is developed in the same repository (kde-runtime, kde-workspace,
> and basically the whole rest of the stack). Only the shell and a few apps
> are developed in a separate repository (which I think is more an artifact
> of us moving to quickly in the past year to clean up after ourselves than
> anything else). The different release schedules ... I don't know.
> 
> On the one hand, we untangling what we currently release as KDE SC, making
> separate releases for platform, workspaces and apps, on the other hand. On
> the other hand, we've thought about releasing the plasma-mobile repo
> together with the rest of KDE SC. We see that requirements for devices are
> a bit different, and that we want to cater for that with an "always
> releasable" system.
> 
> Still, ideally we'd roll stable releases of an always releasable core
> together with SC releases, but are basically able to do a device with the
> latest snapshots at any point in time.
> 
> 
> To me, it's really much more like this:
> 
> 
> 				Plasma Workspaces
> 
>           KDE Platform
> 
> 
> Plasma Workspace includes Desktop, Netbook, Active, Mediacenter, etc.. This
> may look oversimplified, but I don't think it is. Technical details such as
> what you can find in which repository, how packages are split are really
> only technical details for the sake of deployment, but it's certainly not a
> structure we can use to define ourselves and what we do.
> 
> Just like for apps that ship different kinds of UIs, the "Plasma Active
> Workspace" is just a different flavour of the "Plasma Workspace", just like
> the desktop. In most cases it does not make much sense to draw an artifical
> line. (The same holds true for Calligra Active vs Calligra (Desktop),
> Okular, Marble, etc... who all might use different UIs bases on the target
> device. From that, you can derive "Plasma principles" such as "a component
> should work with different formfactors and input devices" and "a component
> should work across multiple devices" quite logically, and I think that's
> the mindset we need to foster.
> I think we're doing ourselves a disservice if we see these things as
> different "projects" or even teams, and we should not to that.

I understand Plasma Active Workspace is a Plasma workspace, just like Plasma 
Desktop and Plasma Netbook are. The Plasma Active Workspace is however 
released separately from KDE SC and that is what I wanted to highlight. Note 
that I don't see anything wrong with that.

My goal with this diagram was to illustrate end-user products and how they are 
grouped under umbrella terms, rather than teams. 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 
and, I guess, the Active UI part of applications like Okular and Marble (at 
least to bootstrap the process of having Active-friendly applications)

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

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.

Aurélien