KDE architecture diagram

[Sebastian Kügler]

On Friday, June 08, 2012 12:35:46 Martin Klapetek wrote:
> On Fri, Jun 8, 2012 at 12:01 PM, Sebastian Kügler <sebas at kde.org> wrote:
> > 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? Here, just like in Plasma, there are a few codepathes that differ
> > per
> > device, but the majority of the code is shared. The differences come from
> > how
> > you configure it for a given target device. That is conceptually the same
> > as
> > with Plasma we're building a system that you can configure for a wide
> > range of
> > target devices.
> 
> While I share your idea of Plasma Workspaces, I would imagine that
> different parts of the kernel are maintained/developed by different people.
> 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. 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. 

Some examples, to prove you're wrong in most cases:

- Plasmoids: can be used without any change on the desktop
- Functionality added in existing plasmoids (see above)
- bugfixes/performance improvements in libplasma: directly benefit all 
  "products" based on libplasma
- all the work happening on dataengines, scriptengines, bindings, scripting, 
  window manager integration -- all device agnostic
- QML Ports of existing functionality: Makes it even more device-agnostic
- Device specific plasmoids: Kickoff and taskbar for Plasma Desktop, Activity 
	switcher for Desktop and Active); for these, you're right, those are only a 
  handful, though, and should hardly be the base for a general statement

> Which I think might be on of the problems - seeing
> the Plasma team focusing on Active, bringing new features there while the
> desktop is...well, it's the same for the past 3 years. 

I don't think that's accurate. Actually, for the sake of an experiment: Take 
Plasma Desktop from KDE SC 4.3 and compare it to 4.9 (you'll get pretty much 3 
years of development).

One fact is that desktop users are rather adverse to change, so we have to be 
very conservative with user-visible changes. So yes, panel's still at the 
bottom, we still have taskbar, startmenu, system tray, etc. 
I don't think that is really related to this discussion (but can easily be 
confused with it).

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

I don't see how that's comparable, applicable, or even a good idea. Change 
should be driven by necessity, not by "well, it's been 2 years already...". 
That just gets us into trouble.

> 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".
> I personally think we need a more precise vision (we already do have
> organic uis, don't we?). For example - what's our vision for integrating
> social media in the shell/Plasma? What's our vision for integrating IM? And
> 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. Those teams 

if those are separate teams, you'll get inconsistent results. They all need to 
be driven by the same vision. Otherwise, results will differ across devices, 
and it will make duplication of work easier (we want neither).

> then lookup to that vision and build stuff to reach
> it. To reach one great Workspace. Just like for Active - you have a vision
> of creating a touch-based interfaces (very simply speaking), so basically
> there's a vision of how you'd like Okular to behave in such environment.

Touch-based is not part of the vision, and never has been. It's an implication 
detail and we need to make things touch-friendly because otherwise their 
applicability is limited to only a part of the device spectrum. Note that we 
built widgets with touch-friendliness in mind years before "Active" was born.

> And I would like to have this precise vision for the rest of the Workspace,
> not just "to have scalable interfaces".

"scalable" comes closer to our vision, but in the end, it also derives from 
the device spectrum concept.

> Each and every team can do their own vision. But then there will be
> inconsistencies, different functionality etc. 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. 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.

You're making the right point here. We need supervision across subgroups, 
ideally, we'll work as one big team.

Understanding that is really at the heart of everything we do.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9