Plasma and KWin Integration

Lubos Lunak l.lunak at suse.cz
Wed Feb 11 17:59:42 CET 2009


 Looks like we KDE people are not used to cross-posting. It would probably 
make sense to keep discussions on only one list (the one from which something 
is wanted).

On Monday 09 of February 2009, Richard Moore wrote:
> Plasma and KWin Integration
> ===========================
>
> This is the results of the discussion on the areas we (the plasma team)
> feel we need help from the kwin team to produce better integration. It's a
> mixture of issues from fairly trivial ones, through complex ones, to those
> that come down to issues with specifications like NETWM. The aim is to
> provide users with the best possible experience running a pure-KDE desktop.

 First of all, I'd like to point out that the KWin team is rather small and 
busy (I personally have had only limited amount of time for KWin the last 
half a year and I don't see it changing soon). Therefore I'm afraid some of 
the solutions for you will be "this is how it should be done, send a patch or 
wait".

> 1. Ability to obtain pixmaps of windows.
>
> There are a number of effects that would be possible within plasma and
> other applications if it was possible to obtain a full pixmap of a window
> (even if it is obscured). This information is available to kwin and used
> for compositing, the idea would be to publish it for use by other
> applications.

 What would they use it for and why is the approach used by taskbar thumbnails 
not good enough?

 Theoretically this should be simple and Plasma could handle it itself using 
the XComposite extension. Any window can be redirected to a pixmap using 
XCompositeRedirectWindow() with CompositeRedirectAutomatic (which means it 
wouldn't depend on a compositing manager in any way). In practice KWin has a 
better overview and can provide such functionality as pixmaps for minimized 
windows, but sharing X pixmaps between processes can be a tricky business. 
Unless you want obscure or complicated stuff just asking KWin would be IMHO 
the easiest. See also next item.

> 2. Better thumbnail scaling.
>
> The scaling algorithm used by kwin to create the window thumbnails seems to
> produce pretty poor results, comparing the results with Qt's smooth scale
> for example. Looking at the code, they appear to be using a codepath that
> generically supports all the transformations used in effects. Could we get
> better results by having a codepath that is specifically designed for
> scaling?

 We could possibly make the code use a better algorithm for the thumbnails, 
but only what OpenGL/Xrender give us. The pixmap is never converted to QImage 
as that could have huge performance impact, so no chance to get Qt's scaling.

 Which also means that if you wanted to get the thumbnail yourself using 
XComposite, you'd have the additional problem of possibly slow XRender 
scaling or other problems that KWin needs to handle when it paints the 
pixmaps.

> 3. Ability to have windows on a specific set of virtual desktops.
>
> Being able to say a window is on desktop 1 and 3 for example. This one
> isn't a big deal, just a 'nice to have'.

 Would need a spec change, but otherwise not very hard, just probably tedious 
to check the change doesn't break code somewhere. If somebody wants to give 
this a try, just ask for details. This BTW has nothing to do with Plasma, 
right?

> 4. Per-desktop struts.
>
> At the moment struts apply to all desktops, which doesn't make sense if
> (for example) you have different panel configurations on different
> desktops. It could also be an issue if a particular desktop was a
> full-screen media center, though in this latter case it can be worked
> around.

 No, struts apply only to their windows, and therefore only to the desktop 
where the window is. If I force the panel to be only on desktop 1, the 
maximize area changes on desktop switches. Maybe you've found a bug 
somewhere, but in general this works.

> 5. Shadows of shaped windows.
>
> At the moment the shadows of shaped windows don't really work, could we
> have something like a separate shadow mask?

 Nothing more to add to that Lucas has already said.

> 6. Marco created a patch that added a shadow to the plasma panel, and
> whilst kwin handled the strut correctly in some cases, it did not in
> others. For example, the magnetic window borders stuck to the shadow rather
> than to the edge of the panel.

 This is expected. Magnetic borders snap to the window, and since the shadow 
is faked inside the window, it snaps to it. You should not be faking shadows 
yourselves unless 5. above proves impossible, and even then the hack should 
be rather helping KWin to do the shadow properly.

 And this has nothing to do with struts. A strut is reserving an area at a 
screen edge so that e.g. maximized windows don't cover it.

> 7. Theming of kwin dialogs to match the rest of the desktop furniture.
>
> Things like the window menu are part of the desktop rather than part of
> applications and it would be great if they were coloured like the other
> pieces of furniture rather than like the applications they manage. The same
> thing applies to a number of other things drawn by kwin such as in the box
> switch effect.

 Just as Lucas, I don't see what you mean with window menu here, but for the 
rest I don't see a problem with adding that, assuming
- it's technically feasible - I don't know technical details, but IIRC it uses 
threads, the idea of which in KWin makes me a bit uneasy
- there's a way to get the old style back - a Plasma theme, let's call 
it "Classic", that would just make things look like they use normal widgets 
and not Plasma's special theming should do

> 8. Document modal windows.
>
> Having a way to handle document-modal windows along the lines of the Sheets
> in MacOS. These would be positioned over their parent window and move with
> the parent.

 This is not Plasma related again, is it? This has been already discussed 
somewhen in the past, and there is http://bugs.kde.org/show_bug.cgi?id=152945 
as a result. But I currently don't have the time and I don't know how 
difficult this would be for somebody else to handle it.

> 9. Hide the panel when zooming out to show the containments.
>
> As discussed already by Sebas, and patch provided.

 Containments? I assume you mean the recent issue with panels and the 
DesktopGrid effect here?

> 10. Alt-Tab to desktop and panel
>
> The desktop and panel need to be able to get the keyboard focus to allow
> users without keyboards to activate and use them.

 This has also already been discussed, with Aaron and Chani IIRC, and I think 
I said that it's just adding new shortcuts and adding new mode in 
kwin/tabbox.cpp that would consider only isDock() and isDesktop() windows.

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


More information about the Plasma-devel mailing list