KDE architecture diagram

[Aaron J. Seigo]

On Friday, June 8, 2012 12:35:46 Martin Klapetek wrote:
> While I share your idea of Plasma Workspaces, I would imagine that
> different parts of the kernel are maintained/developed by different people.

and they don't whinge at each about it ;)

> Sure, the core is the same, but the platform-specific stuff needs to be
> different (if only a little). So one needs to see the difference between
> core and the "workspace" in our Plasma case.

the "core" makes up 95%+ of the "workspace".

i'm beginning to think that people are judging on the looks rather than the 
code, and that worries me because it would mean people are making conclusions 
without knowledge.

the design of Plasma lets us take the overwhelming majority of code and re-use 
it across workspace shells. that's the entire point. i've calculated that the 
current delta between Active and Desktop is ~15000 LOC, and that once we merge 
some branches (e.g. the QML screen locking branch) that will drop down to ~10k 
LOC. the other ~250 LOC (not counting kdelibs, qt, and all that of course :) 
is shared.

from libplasma to the script engines to the plasmoids themselves there is 
great consistency.

so differentiating between core and workspace is not as useful as one might 
expect at first.

> In other words - if you add
> method to the core and make use of it in Active, it doesn't magically
> happen on desktop too.

not always, but often yes it does. did you notice the new activity manager.

> Which I think might be on of the problems - seeing
> the Plasma team focusing on Active, bringing new features there 

many of those new features are available to and have appeared in the desktop. 
the new activity manager daemon, the QML components, improvements in various 
plasmoiods, etc. 

there is still much more to take advantage of in Desktop, and thankfully the 
design lets that happen easily. the same design that has let us do Active. it 
is *not* a zero-sum game where Active takes away from Desktop or vice versa. 
efforts in one improve the others. they also bring in more developers.

there's also the fact that working on a touch interface gives new interest in 
and perceived (and real) sustainability to the KDE Workspaces.

let's look at the big picture here.

btw, it sounds very whingy when people get annoyed that we've worked on Active 
just because they'd like us to work more on Desktop. it sounds very much like 
we're being told "do what *i* want". well, all of us who worked on Desktop and 
now contribute to Active have also continued working on Desktop in parallel. 
who do you think did the new Applets chooser, work of libtaskmanager and the 
tasks widget, etc. etc.?

my hope is that instead of whinging at us about working on Active and ignoring 
our parallel efforts on Desktop, that people will pitch in and work on the 
parts that interest them and move those things forward faster.

> desktop is...well, it's the same for the past 3 years. 

tasks launchers, new window switcher (in QML no less :), several plasmoids 
ported to QML (only somewhat user visible in that the results are usually 
graphically smoother, but necessary work), addition of javascript for the 
layouts (and many improvements to that in the last 18 months), system tray 
refinements, the Plasma KPart now used in a number of apps ...

now, i do understand what you're saying: the desktop hasn't had a major set of 
visual changes in the last few years. it's all been incremental and 
evolutionary. that does *not* mean people have not been working on it or 
caring for it.

performance improvements and bug fixes are critical to the maturing and 
therefore the adoption of the desktop interface.

> And just look at
> Facebook - they change stuff every 2 years or so. Now I'm not saying let's
> forget what we have and start over. Not at all. But we're quite stagnating.

compare 4.5 with 4.9. use 4.5 for a week or two, then come back to 4.9. 
there's been forward movement.

now, when we make change, we need to be able to say why we're making those 
changes. change for its own sake is useless. which means that not doing a 
revolution every N years is not necessarily a bad thing. major changes should 
happen when they need to. not sooner, not later.

so saying "we're stagnating" when we not only have things like Active going on 
(which really takes the wind out of our sails, btw: "what you're doing has no 
value" is exactly how it ends up sounding like.) but also moving Desktop 
forward is ludicrous. btw, if you want to see a shell that is stagnating: 
Netbook. it hasn't seen any major work in a while.

so if we wish to talk about stagnation let us:

* stay real to the actual efforts, not invent "nothing has been happening" when 
there has been

* define what change we want to see and describe why that change should happen. 
speaking in generalities ("it's stangating") will not move things forward.

> And that's in my opinion, where we need the vision. Aaron's vision is
> great, but to me it sounds more like a general textbook "workspace vision".

can you point me to another workspace that is doing what we're doing? 

or, go back 8 years when i did my first presentation on the prototype of this 
vision at Akademy in Ludwigsburg and compare the ideas of what a desktop was 
then to what it is now ...

> I personally think we need a more precise vision (we already do have
> organic uis, don't we?). 

in some places. we still have work to do in many places. and we only have that 
now because we had that vision in the first place. other workspaces were not 
looking at this, especially not KDE.

> For example - what's our vision for integrating
> social media in the shell/Plasma? 
> What's our vision for integrating IM? And

great questions! :)

they are also domain specific, akin to "what's our vision for managing files 
from the desktop?"

there is a global "first principles" vision. i think it can be refined and 
improved.

based on that we have domain specific visions. like "how do we integrate social 
media better?"

btw, are you familiar with Share Like Connect?

> so on. Sure, there are teams doing these tasks, but we should imho have a
> common vision, or goal if you wish, clearly defined by the Workspace
> leaders.

agreed.

> it. To reach one great Workspace. Just like for Active - you have a vision
> of creating a touch-based interfaces (very simply speaking),

that isn't the vision of Active. "touch based" is a domain-specific 
implementation vision within Active (the domain is "tablets"), but the goal is 
to also support set top boxes and other form factors that are not 
primarily/exclusively touch. 

the actual vision is in 3 quick points. the UX goal is: "an interface that 
adapts as users change Activities".

the other two parts are:

* a fast embedded UX platform with minimal memory requirements
* customizable and modular to support different form factors

in support of this we have a HIG in formation to describe our visual and 
touch-based UI language.

if you're wondering where i found this information, it's all on the main page 
of plasma-active.org right near the top.

> so basically
> there's a vision of how you'd like Okular to behave in such environment.
> And I would like to have this precise vision for the rest of the Workspace,
> not just "to have scalable interfaces".

you mean something like:

* an interface that adapts as users change Activities
* integrate social interation patterns with the desktop
* seamlessly blend all "system" (from a user's POV) UX into a single 
uninterupted visual design to frame applications with

this is what we've been working towards all this time, btw.

if you want to know why we aren't fully there yet, i'd be happy to share the 
last 4 years of history of the project.

> Each and every team can do their own vision. But then there will be
> inconsistencies, different functionality etc. 

agreed. we need to come together. that's what the intent was here. i think it 
got off to a very poor start because some people think they know what we've 
been doing, what the design of plasma is and they haven't bothered to do any 
actual research .. while being quite willing to share their opinions.

> Just look at System Settings
> - common place for so many apps and yet each module looks different. And it
> looks bad in the final result.

interestingly, the #1 thing people often write about Plasma Desktop when 
reviewing it is how beautiful it looks and how everything seems to fit.

we know they are wrong ;) and that much is left to be done. but i am also a 
big believer in realism. if we overstate how shitty things are, we will be 
more likely to change things that do not need it, or even just give up because 
after all this effort things still "suck".

> So I think there should be some well
> understood "lead", a way the Workspace should go. Which currently there's
> not. Or it's not well known.

it's just not well known. or, more accurately, it has been ignored. it used to 
be fought against, then it was ignored and now ... 

btw, did you know that just recently a developer on this list started working 
on harmonizing the tooltips between dolphin, system settings and libplasma, so 
we'll have consistency there?

there was also a discussion on g+ (not a good location, i know :) about 
QML'ifying system settings between myself and the system settings maintainer 
(and others). we'll probably take things we've learned from Active Settings 
and apply it there.

and you do realize that when we started, KWin was also a separate component. 
it was only because we invited KWin in and the KWin developers really "got it" 
why this was important. as a result, KWin has brought all sorts of 
improvements and new ideas to the table that would never have happened without 
them. we shared a vision, we shared development effort, we brought things 
together. even with kwin, there is still vision sharing to be done (as can be 
seen in Martin's recent emails :), but we have been picking up the pieces and 
bringing them together.

as for apps, many design concepts in today's dolphin have come directly from 
the workspace vision we've had. we do need to take this further out, but we 
have been bringing the ideas to those who have been open to them and within 
the limits of how fast our hands can write code.

i could point to any number of similar things in KDE3 that now work/look 
seamless in Plasma Desktop.

and now that you are here, we can go even further together! :)

the reason it hasn't gone further sooner? in part because these things take 
time. we had a lot of work to do in Plasma to get us to this point (and Qt 
changing about so much in the last 5 years did not help). 

in part because KDE people were not ready for this discussion. it used to be a 
hobby of some KDE hackers to take a shit on Plasma on the mailing lists, in 
their blogs, on web discussion boards and even in person. how could we have 
these discussions when that was the atmosphere?

now more people see that Plasma may be on to something and the idea of working 
together to bring about a seamless workspace starts to make more natural sense 
to people. it also helps that some of our competition has also moved in this 
direction (and to some extent they have done so because of Plasma), which 
helps more KDE people understand this is a good thing to prioritize.

but the Plasma people have been here for 3-4 years trying to make this happen 
and writing code that has brought it this far. i'm glad it finally is happening 
faster and with more people, because we all agree it's the best way forward 
and we need more hands.

denying the work and effort we've put in or the leadership we've offered is not 
a nice way to start this, however.

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