Next Iteration Sprint, confirmed !

[Marco Martin]

On this issue i must admit i still don't have a definite opinion, so what 
follows are some toughts on random directions on the topic.

I see in both approaches solutions to many problems and cause of a new set.

having worked on the plasma active window strip in various incarnations makes 
me feel a little we did hit a wall on what's possible. the current solution 
works, but has problems.

<intermission>
so what we have now (little explanation to get everybody in context of this):
a window managed by plasma-device that stays on top of the screen. it's the 
panel and is partially offscreen because can be pulled in to uncover the 
laucher and the window strip.

of the two, the launcher is done by the shell, the windowstrip by kwin 
(because only kwin can draw live window thumbnails) it means is another 
window, another process, but it must look like this isn't the case, so with an 
atom that instructs to do so, kwin keeps the switcher window over the panel 
window, at a certain relative position. Another problem comes that both 
windows should be able to manage input, so when there is mouse/touch over the 
kwin window, it reforwards it over the embedding panel window and this isn't 
perfect, besides being ugly is quite slow and is clearly possible to see the 
position on the two windows lagging a bit.
</intermission>


so, this tells that we really need a way to integrate things more, because we 
could need more and more things like uis to manipulate windows thumbnails or 
windows that needs to behave in own, peculiar way.

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)

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


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?)


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.

> > 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
and there would still the problem of when one crashes all goes down.

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

Cheers,
Marco Martin