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

Thomas Fjellstrom tfjellstrom at strangesoft.net
Fri Nov 23 09:19:39 CET 2007


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

Because it actually isn't _just_ showing the desktop. its a plasma specific 
action. You get full screen OVERLAY (as was mentioned), of ALL of your 
plasmoids. Which are likely re positioned and possibly resized to all fit. It 
should even include all of the plasmoids from all virtual desktops and 
screens. All neatly arranged in a possibly translucent overlay.

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



-- 
Thomas Fjellstrom
tfjellstrom at strangesoft.net


More information about the Panel-devel mailing list