kde plasma workspace structure

[Martin Gräßlin]

On Saturday 09 June 2012 16:29:10 Aaron J. Seigo wrote:
> 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.
I don't know. It was just the first bug I found regarding non-composited 
setups by going through the list of bugs from top to bottom. I knew there was 
one recently :-)

But there are more, also in support threads I have seen such issues come up.
> 
> > > 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.
Give me your kwinrc and I tell you which one to turn off :-) Seriously: 
disable track mouse effect as it polls the mouse position.
> 
> > > 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.
I don't know, but for me the benefit cost ratio is very bad. We have huge 
costs to support the non Linux-OSes (such a compile error is at least half an 
hour of work) while we get back nothing on the benefit side. If we would at 
least get back some feedback on how well it works or not at all it would 
already be worth the effort. But at the moment I say "screw it" whenever it 
would happen again that KWin won't compile on non-Linux.
> 
> > > 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.
it's also a decission for us to make. E.g. the Wayland branch of KWin would 
not compile (though everything is ifdef-ed at the moment). At the point where 
we say Wayland is a hard build requirement for our Workspaces, it would stop 
to build on non-Linux OSes.

And as said above: if the cost/benefit ratio does not increase I would 
probably not be willing to invest the extra amount of insanity to add ifdefs 
around each second line of KWin code :-)

It's also something to think about that we want to switch in the long term to 
a window system unsupported on non-Linux OSes.

Cheers
Martin
-------------- 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/ed510225/attachment.sig>