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

[Lubos Lunak]

On Tuesday 20 of November 2007, Aaron J. Seigo wrote:
> On Tuesday 20 November 2007, Lubos Lunak wrote:
> >  That's because in the usual cases, just the window manager and libraries
> > should handle it on their own. Moreover, the window manager is
> > responsible for handling toplevel windows and usually knows better than
> > applications trying to have their own ideas about how things should work.
>
> the window manager does not understand how a desktop workspace should work.
> all of its policies are geared towards window- and document-centric
> applications, neither of which describes the desktop.

 Which is fine. The window manager takes care of toplevel windows, desktop 
keeps the desktop contents inside its window and the window manager doesn't 
need to care about that.

> this is, in fact, why we have things like struts for panels.
>
> like it or not, the workspace needs a lot of special considerations from
> the window manager. we should not be fighting on this, but figuring out how
> to make each work together well. imho, that starts by recognizing these two
> things:
>
> - the window manager should be used to actually perform as many of the
> results as possible (that's the plasma team's part)
> - the window manager needs to accept much more direction from the workspace
> for its elements than it normally would need from a regular app (that's the
> kinw team's part)

 I said there are special cases and the desktop is certainly one of them. 
That's why I want you to talk to me before making any special things WRT 
toplevel windows, so that it can be handled properly on both sides.

> >  I would like to have such page though, but it'd probably have to mention
> > various things as they turn up. Do you have any specific issues in mind?
>
> - 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.

> 	- 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? How do you want to handle that code-wise when many 
people can't handle even the QWidget*parent stuff properly :( ?

> - how to handle dashboard like overlays

 I still need to be told what dashboard is supposed to be.

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

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