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

[Aaron J. Seigo]

On Tuesday 20 November 2007, Lubos Lunak wrote:
> On Saturday 17 of November 2007, Ivan Čukić wrote:
> > >  I'm pretty sure I've already told Aaron, but let me repeat for
> > > everybody:
> > >
> > >  When you get some fancy ideas about toplevel windows (and this is
> > > bound to
> >
> > Could you put your directions on the techbase?
>
>  Direction number 1: Whatever you want to do, don't do it.
>
>  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.

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

- how to handle dashboard like overlays

- top level windows w/out borders: both how to do them and when not to do it.

> > I have one a bit related question - how to tell KWin not to draw shadow
> > for a paricular window. The problem with us, Plasma people :), is that
> > sometimes we have non-rectangular window (Lancelot, Raptor) and it looks
> > awful to have a shadow made by transparent window parts.
>
>  Ok, a nice example of the above :). Transparent window parts should not
> have shadows, so this is obviously a KWin bug that needs to be fixed,
> instead of trying to work it around by some flag. I'll add this problem to
> the 4.0-TODO file.

sweet, thanks =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071120/517b88e2/attachment.pgp