Thoughts on the Iteration Sprint, discussions and criticism

[Aaron J. Seigo]

On Wednesday, June 6, 2012 01:09:55 Aleix Pol wrote:
> I've always considered Active a Project on top of KDE/Plasma because
> it carries concerns out of the scope of the shell, like the OS. What

Active has the same relationship that Plasma Desktop and Plasma Netbook have. 
it has also driven much of the improvements and innovation in libplasma and 
kde-runtime support for plasma in the last year.

so in one sense, it is a project on top of KDE Plasma .. but so is Desktop and 
Netbook. and they are all joined together because a fundamental concept is to 
write components (visual and data) and design interaction concepts once and 
re-use them between the different target device form factors.

the reasons for this are:

* we do not have the manpower to do a separate technology for each device type 
we'd like to target

* the user gets a more dynamic, consistent and better tested environment when 
the technology is shared

this is what we mean by "device spectrum". we'd like to add other categories 
of devices as we go. as we do this, they also need to work seamlessly with the 
other existing device targets. for this reason, it is critical to see all 
these efforts as one extended effort with huge overlap. trying to divide the 
different shells into their own worlds will erode the benefits above and likely 
doom the device spectrum effort completely.

so that's where they are the same... Active is also different in 2 ways: we 
also have people working on the OS stack (because we need to support one 
ourselves, not because we want to do this; thankfully we get this "for free" 
on laptops/desktops :) and we work on some critical applications which on the 
desktop we have other developers happily doing.

these apps are built on existing KDE code, however. for instance, we took 
okular and threw a bit of QML on top to make a ebook reader, and that lives in 
the okular repo. i would realy like to get out of the app effort, but until 
other people get the burning urge to write touch appropriate UIs for their 
apps, we need to help out. 

in future, our app involvements should merge back into KDE's usual application 
devel community. some apps (Marble, Kontact, Calligra) are already self-
sufficient; we're just filling in the cracks with things like ebook readers, web 
site chrome, file manager, etc. so while it is a short term necessity, this is 
the biggest part of Active which is not applicable to the rest of our Plasma 
efforts, and should generally be ignored when trying to figure out what the 
Plasma Active <-> Plasma Desktop relationship is.

what i think we can learn in Plasma Desktop from the app effort in Plasma 
Active is that concepts like activities, share-like-connect and common UI 
language are very compelling when applied to applications. this is certainly 
an area that core KDE applications could improve, and the goals (or reasons) 
for this can be seen in how Active has ended up looking and working.

> Now I've always considered that this was fine (even after being to the
> PA3 sprint). You can widen the definition and say that Active can fit
> the desktop, but then it turns quite blurry to me what is what. I

Active does not fit the desktop, it _is_ the desktop, and vice versa.

the same technology is used across all form factors. innovations done while 
working on Active apply to Desktop, and vice versa. only relatively small bits 
at the top of the UX change. 

this is also not a widening of the definition, it is how it has always been 
from day 1. 1-2 years before Active was started we were talking about device 
spectrum thinking.

> Maybe a Venn diagram of what is Plasma, Active and KDE, would be helpful.

KDE is a community, so there's no intersection there. :)

Active is the act of bringing Plasma to consumer electronic devices that are 
more like appliances than the usua desktop/laptops we target with Desktop and 
Netbook; our starting point is (relatively) large-screen touch devices.

Plasma is the combination of:

* underlying technology design (libplasma, kde-runtime/plasma/)

* the shells (plasma-desktop, plasma-netbook, plasma-device)

* the required applications to create a full workspace (window manager kwin, 
run command krunner, system monitoring ksysguard, etc.)

* core components (plasmoids, DataEngines, QML components, data models, etc.) 
for essential use cases (we try to leave other components to the larger 
community; everyone deserves to have some fun too :)

-- 
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/20120606/9ebe1b2b/attachment.sig>