Next Iteration Sprint, confirmed !

[Martin Gräßlin]

On Saturday 05 May 2012 14:15:02 Marco Martin wrote:
> but having the shell and windowmanager merged in one process also gives
> strong side effects, as noted from stability to speed. a cpu intensive task
> by the shell can slow down the whole window namager (and i would love the
> window manager having the least possible number of things to think about in
> its event loop)
very true concerns. Solutions:
* only QML applets (stability)
* DataEngines out-of-process aka libplasma2
* Compositor runs in own thread (/me wants that for 4.10)
* Scripts run in own thread (no idea if really possible as it would require 
two gui threads)
> 
> one partial solution could be having just parts of the shell moved in the
> vm, so regarding plasma desktop would be the whole thumbnail window,
> regarding plasma-device would be the whole top panel. In this case tough
> since the panel is a containment it would make the windowmanager kindof a
> shell anyways, having a corona, containment, applets and whatnot indide it.
yeah, that's what I meant with what's left from the desktop shell if things 
are moved into KWin.
> Besides wasting memory, potentially slowing dows kwin on the desktop there
> would be also the problem of moving applets between the panel and the
> desktop.
such issues would of course need to be addressed.
> 
> 
> in the end what is needed is really to paint one window inside another and
> sharing the input in some way... does wayland have anything about painting
> embedded windows? (ideal would be textures shared by different processes,
> then input is completely managed by the shell, don't think will be ever
> possible?)
I am not aware of Wayland supporting that and I expect rather no. At least the 
reference implementation Weston integrates shell and compositor and the 
Wayland API (when I last looked at it) contained strong indications that it 
consideres compositor and shell being one thing.

As windows are just buffers it would probably be possible to pass the buffers 
from KWin to Plasma which would turn Plasma into a compositor and well that's 
kind of the same thing as turning KWin into a Desktop Shell. Further problems 
would be the damage handling which is I think not considered to be passed 
around.
> On Saturday 05 May 2012, Martin Gräßlin wrote:
> > Using a window class to identify is acceptable in an effect, but not in
> > KWin core. It does not perform checks on window classes, but only on
> > window types and attributes certain functionality to these window types.
> > 
> > This would require a special window type for dashboard and then the
> > semantics would have to be implemented inside KWin.
> > 
> > Obviously the same is needed if Dashboard were in KWin with the difference
> > that we can use Q_PROPERTIES.
> 
> more than window classes for particular windows could be more "i want to be
> managed according to the following rule set file i provide"
> 
> so if the window says that it wants to be managed according to the schema
> "org.kde.footron" kwin could look for a rule with that name that would say
> stuff about window borders, being in taskbar who to appear over who to
> appear bottom etc. it would still be free to not follow one of those
> properties if doesn't want to or considered dangerous.
yeah that would be the window type.
> 
> > > and allows process separation. read "kernel level
> > > context switching for smoothness". if you doubt that this matters, check
> > > out how Marco made the appearance of the "Add to activity" and
> > > "Configure Activity" UI's smooth in Plasma Active -> kwin (a separate
> > > process) animates the show of the window while plasma-device spins on
> > > data gathering. when it was in one process -> slow. two processes?
> > > smooth.
> > 
> > couldn't the same be achieved with two threads?
> 
> would be two gui threads, that's... ouch
ah ok, I thought it's some background processing
> and there would still the problem of when one crashes all goes down.
we don't crash :-) (Seriously: I would love to see us all get to the point 
where we just can omit the crash case).
> 
> > > and then we need to think about different shells. when the shell is done
> > > by one process, switching shells at runtime is conceptually simple and
> > > should be doable without interupting the user experience. if it means
> > > re-starting the window manager too? nope. moreover, by having the shell
> > > external it gives nice clean separation.
> > 
> > No I'm not considering that it would need restarting the window manager as
> > all that is needed is unloading one plugin and loading another one :-)
> > 
> > > or do you one want one plugin which is plasma-device, and another which
> > > is plasma-desktop, and another which is . .meh.
> > 
> > I don't want to change any of the existing shells. Plasma-device should
> > stay plasma-device, plasma-desktop should stay plasma-desktop.
> 
> there may be some tempting parts in having shells as plugins...
> 
> > Oh and just for the record: moving the complete desktop shell inside KWin
> > would violate the KWin mission statement I put up myself a few weeks
> > before
> > I wrote that mail. In fact I wrote it a day after I realized that we need
> > to move Plasma into KWin. So whatever we do I would still see Plasma as an
> > independet part just connected closer to KWin so that we can do more for
> > it.
> 
> yep, i agree there is need for more integration, the epi hack to make the
> window strip work in plasma active clearly shows this, i still cannot see a
> way with ugly side effect tough
You probably meant without, right?

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/20120505/8139cf72/attachment.sig>