KDE architecture diagram

[Aaron J. Seigo]

On Thursday, June 7, 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,

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.

> have different release schedules

a small digression first:

the One True Release Cycle is a legacy of KDE being a smaller project in the 
past. before extragear (long, long ago when the earth was young), *all* KDE 
applications were released in the One True Release. there just weren't that 
many apps, and all the apps being worked on were applicable to all / most of 
our audience.

Frameworks 5 will be released before Workspaces gets ported to it. and there 
is nothing set in stone that says Workspace will from that point forward only 
have releases every 6 months. (though i expect we will at the very minimum 
sync a release with Frameworks every N months)

i'd also love to see plasma-addons released much more regularly, or perhaps 
not released at all in the traditional sense and only offered as add-ons 
through an applet store ala hotnewstuff.

ok .. back to the case of Plasma Active itself. the reason for the decoupled 
release cycle is due to the realities of getting the project going and the 
needs of companies making devices. this is why e17 has never had, and from 
what i understand never will, have a proper official "release". (we won't go 
that extreme :)

but the decoupled release cycle is not indicative in this case of a decoupled 
technical design, goals or aims. Plasma Active was born out of the same vision 
and goals that gave birth to Plasma Desktop and Plasma Netbook. it was the 
same people, the same goals, the same technical design. they (we) saw it as 
the same project. they still do.

> and target different devices.

so does Netbook, but it's in kde-workspace.

but consider this: since the beginning of Active we've been talking about 
eventually having a tablet powerful enough (CPU/memory/storage) that you can 
have both Desktop and Active on the same device and when you dock the tablet 
(or even just sit it upright and connect a keyboard+mouse) it would switch to 
desktop. these devices are on the market today, so we aren't far from it.

the ability to switch shells was pionered with Plasma Netbook. which in your 
diagram is part of KDE Workspaces. :)

so it can't be the device that is being targeted since those lines are not 
definitive. 

the reason for the different workspaces comes down to meeting different use 
cases and interaction patterns. there's a high degree of corelation between 
use cases, interaction patterns and the hardware one chooses. but what we've 
seen in the last decade is that those choices are converging. a phone is no 
longer just a phone, for instance :)

-- 
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/a5a0766c/attachment.sig>