kde plasma workspace structure

[Aaron J. Seigo]

On Saturday, June 9, 2012 14:13:49 Martin Gräßlin wrote:
> On Saturday 09 June 2012 13:18:04 Aaron J. Seigo wrote:
> > On Saturday, June 9, 2012 12:37:47 Martin Gräßlin wrote:
> > > There might be a misunderstanding. I do not say that we have to require
> > > OpenGL compositing, I'm saying that the stack underneath us broke for
> > > the
> > > non composited case (either XRender or OpenGL). If you want I can search
> > > for the bug reports where things are broken only for non-composited
> > > setups
> > > (that is a complete shift over the last two years).
> > 
> > yes, i'd appreciate it if you could.
> 
> an example would be #300996

if this is the root cause:

"The trigger is likely that plasma (still?) at least used to repaint the 
entire desktop whenever an extender was shown - the core problem is that 
there's no backing store and no compositor."

then that is something we need to fix in plasma-desktop.

> > btw: i run without compositing on my main laptop most of the time. other
> > machines in the house run with compositing on.
> 
> May I ask why? And have you considered using XRender? I would be surprised
> if it would not render your system snappier

so at least one of us is testing non-composited setups :)

composite works really rather well for most/all apps i use on this laptop, and 
when i turn it on i can not perceive any real slow down.

i have a suspicion it takes *slightly* more battery on my laptop, but i have a 
sneaking suspicion that may be due to one or more plugins i have enabled and i 
have not done the requisite powertop and config tweaking checks so i have not 
yet said anything. such hunches are so unreliable esp when the differences are 
in the single digit %s that i want to get real #s first.

> > they test it. that's the entire point of distributed, open development: we
> > don't have to do everything. this way even groups in the minority can get
> > the service they want.
> 
> But I don't see them test it. E.g. I know that for at least a year KWin is
> non functional with mesa drivers on BSDs, but there is no bug report about
> it.

perhaps they don't care about it, or they know what the problem is and it is 
too much "heavy lifting" for them right now (e.g. perhaps it means some 
upgrade / hacking on mesa on that platform) ... perhaps they are just happy / 
fine with the non-composited system.

and if we abandon them they won't be.

> > there is a difference between saying "you have to test this.." and "we are
> > dropping your platform so you can't even do that." the latter closes
> > doors.
> 
> agreed in that, though I think we already reached the point where the door
> is almost closed. And there is lots of functionality out there ready to be
> used in KDE which will make it harder and harder, think of systemd, Wayland
> (theoretically possible one BSDs support KMS), udev, ...

this is fine. this is a decision for them to make, not us. and i remember the 
same arguments made for HAL and various other linux advancements, btw.

this is also one of the strengths of our current platform design principle of 
"clean front-end API that describes capabilities with back-ends that implement 
those policies using system native services" -> as we move on to udev others 
can keep the older backends working.

this is the principle of "walking on two legs": we put one down in front while 
the one behind keeps us from falling over.

go look at the shitstorm that happend when xfce moved forward without 
preserving older capacity for their users: users of slightly older linux OSes 
and non-Linux OSes were unable to upgrade and take advantage of other 
improvements and that did NOT go over well. the excuse from xfce? "we write 
dirctly to the system API". if only they had a nice front end / back end split 
and allowed those who care to to maintain those backends. this is the 
principle of "hopping on one foot".

as an exercise, imaginge hopping to the grocery store and back (including when 
you have your groceries in hand ;) versus walking. it is the same thing.

as workspace developers we need to be a bit split-personality because we work 
on both apps and libs at different times and so at different times we need to 
think in different manners:

* when writing our apps, pretend the public API is the only thing that exists
* when writing the public API, consider the forward momentum opportunities 
available to us

to go further with this, some feel that phonon's multiple backends over time, 
with some improving and others dieing out then coming back then dieing and how 
at any given point in time maybe only one is reliable is a sign of its 
weakness. it isn't. it's a sign of its strength, because the application code 
has not been affected one bit making us extremely nimble and our users have 
been largely insulated from the topsy turvy world of F/OSS multimedia.

the same is true here where we need to make very certain that as we take steps 
forward we employ the "many legs" approach, take advantage of multiple back 
ends and allow ourselves to hold the contradictory viewpoints of the app 
developer and the system developer simultaneously in our minds as we work on 
the workspace.

this, btw, is one of the biggest reasons getting the workspace technically 
great is so difficult. hopping on one foot is a hell of a lot easier ... until 
you decide to change directions or have to maintain it 5 years later.

with kdelibs 4.x and our current workspaces, the maintenance load has 
maintained and even pace with the code size, despite numerous changes in the 
technology beneath us on the OS (udev, *kit, blah blah blah) and our growing 
number of users of the 4.x series. it is no harder to hack on things now than 
it was 4 years ago. in fact, as we've incorporated newer tools, also in the 
"walking on two feet" fashion (so we adopt QML, for instance, incrementally, 
which the design allows for), it's gotten *easier* not harder.

kde3 was the exact opposite. the longer that code was maintained the harder it 
got to do anything with it because it was often "hopping on one foot".

food for thought

-- 
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/20120609/929f9d12/attachment.sig>