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

[Aaron J. Seigo]

On Wednesday 21 November 2007, Lubos Lunak wrote:
> 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.

try any of the applet configuration dialogs.

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

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

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

-- 
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/20071121/cee783f3/attachment.pgp