KDE architecture diagram

Aaron J. Seigo aseigo at kde.org
Fri Jun 8 12:31:08 UTC 2012


On Friday, June 8, 2012 14:01:45 Aurélien Gâteau wrote:
> Le vendredi 8 juin 2012 12:20:43 Aaron J. Seigo a écrit :
> > > If I am not mistaken, kde workspace and plasma active are developed in
> > > different repositories,
> > 
> > kde-runtime is also developed in a different repository. so is folderview,
> > which is definitely part of KDE Workspaces; it's also in Plasma Desktop,
> > but not Plasma Active. where something is developed depends on a number
> > of factors: how it is packaged, what its dependencies are, development
> > conveniences .. etc.
> > 
> > when you consider that QML bindings which are now critical to all the
> > Workspaces are in kde-runtime, folderview is in kdebase-apps and only
> > relevant to Desktop and Netbook, that the DataEngines in kde-workspace are
> > critical to all Workspaces, that the QML components in kde-runtime were
> > developed first in plasma-mobile and then migrated there when they were
> > ready for wide use so we can use them in all Workspaces .... it becomes
> > apparent that repository structure does not beget the technical design.
> 
> As I answered to Sebas, I was not aiming at charting technical design, but

ah, then i was confused by the title "KDE Architecture Diagram" and the 
inclusion of things like kdelibs.

> rather at identifying products and how they are grouped.

why is this important? or rather, what are we trying to undestand here from 
doing this?

(and in the case that we do want to identify product groupings: Netbook needs 
to be split out; there should be an entry in there somewhere for the KPart; 
and we should probably have a devel tools section)

> > > and target different devices.
> > 
> > so does Netbook, but it's in kde-workspace.
> 
> True, the argument they target different devices is not relevant and should
> be ignored.

cool :)

> Nevertheless, from a product point-of-view, KDE SC ships (among other
> products) two Plasma workspaces, Plasma Active ships another one. To the
> end- user (and I guess the new developer) they are different products.

KDE ships three workspaces. 2 are released in a 6 month cycle in tandem with 
the rest of the packages, the other (Active) is released on a separate 
schedule. the division between SC and not-SC is a release engineering 
implementation detail and says nothing of the product grouping or relevance.

it would be like saying that Calligra, Amarok and Digikam are somehow of a 
different class compared to KMail because KMail is in the SC. that is not how 
we've been dealing with applications for years now.

> Which developers work on which products is orthogonal to the fact they are
> different products: when someone talks to me about KDE SC, KDE Workspace,
> or Plasma Active, I care about what technical artefacts (as in binaries,
> libraries, components, data assets) those terms encompass, not who wrote
> the code 

if we look at the technical artifacts, it is apparent that Plasma Active is 
one of the KDE Workspaces, on equal terms to Plasma Desktop and Plasma Netbook 
(and vice versa), and that work on one improves the others.

-- 
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/3375d706/attachment-0001.sig>


More information about the Plasma-devel mailing list