[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Next Iteration Sprint, confirmed !
From:       Marco Martin <notmart () gmail ! com>
Date:       2012-05-05 12:15:02
Message-ID: 201205051415.02389.notmart () gmail ! com
[Download RAW message or body]

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 mak=
es =

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 t=
he =

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 th=
e =

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 o=
r =

windows that needs to behave in own, peculiar way.

but having the shell and windowmanager merged in one process also gives str=
ong =

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 ev=
ent =

loop)

one partial solution could be having just parts of the shell moved in the v=
m, =

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 pa=
nel =

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 deskt=
op.


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, t=
hen =

input is completely managed by the shell, don't think will be ever possible=
?)


On Saturday 05 May 2012, Martin Gr=E4=DFlin 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 appe=
ar =

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 befo=
re
> 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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]