[Panel-devel] Plasma and the window manager (Re: KDE/kdebase/workspace/plasma/plasma)

[Lubos Lunak]

On Thursday 22 of November 2007, Aaron J. Seigo wrote:
> On Wednesday 21 November 2007, Lubos Lunak wrote:
> > On Tuesday 20 of November 2007, Aaron J. Seigo wrote:
> > > - how to position diaogs properly for desktop components; that means:
> > > 	- on the current desktop, whatever that is, not the desktop of origin
> > > (open up a configure dialog for most any applet other than the desktop
> > > you start on when first logged in)
> >
> >  Parse error, sorry. If you're talking about Plasma dialogs opening on
> > the current desktop, they do so.
>
> try any of the applet configuration dialogs.

 I don't see any problem, clean setup, build from Tuesday, with settings 
dialog for either clock or battery.

> > > 	- near the item (on the desktop, these dialogs are more contextual
> > > than usual; the "app" is not the desktop itself, but the
> > > widget/plasmoid they are related to, so positioning needs to be rather
> > > different)
> >
> >  There's currently the mouse-placement rule for Plasma dialogs (that I
> > still need to move and fix), that should be good enough for 4.0. For
> > later, do you mean that Plasma dialogs should carry information about the
> > geometry of the applet that opened them?
>
> probably not, for the reason you mentioned. only if i can get this fully
> encapsulated inside of libplasma itself would i even dream of it (again,
> for the reason you mentioned ;)

 Then I don't see any better way than the KWin mouse placement rule.

> > > - how to handle dashboard like overlays
> >
> >  I still need to be told what dashboard is supposed to be.
>
> press ctrl+f12 ... it creates a full screen overlay containing the current
> desktop's widgets; if you have composite going it's even translucent so you
> can still see your windows in behind. this results in a rather nice way to
> bring the desktop forward/back. remember "show desktop" from earlier kde
> (and windows? same problem, different solution.

 How is it different? Why doesn't it use "show desktop"? To me it doesn't seem 
to be really different and handling it in Plasma will again lead to 
problems "show desktop" used to have until I implemented KWin support for it. 
It may need some tweaks, like for the transparency, and this code may still 
need to stay for WMs that wouldn't support it, but I don't see any 
fundamental difference.

> > > - top level windows w/out borders: both how to do them and when not to
> > > do it.
> >
> >  Given KRunner, you've already figured out the how, and I still maintain
> > that normal window should normally have borders, therefore I still see
> > "always" as the right answer to "when not". This may be different with
> > different window types, but then the semantics are based on the window
> > type and then again it should not be specified explicitly.
>
> ah, yeah, this was just a list of things we should incldue on such a page..
> not open questions =)

 Oh, I see :). My answers however make the list somewhat shorter.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz