Plasma and KWin Integration

[Lucas Murray]

On Tue, Feb 10, 2009 at 6:53 AM, Richard Moore <richmoore44 at gmail.com> wrote:
> Hi All,
>
> Here's the write up of the kwin and plasma integration discussion at Tokamak.
>
> Cheers
>
> Rich.
>
> 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.
>
> 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.
>
> Our idea was that maybe this could be handled in a suitably performant way by
> using QPixmaps that share an XPixmap handle between both kwin and the client
> application (plasma in our case).

The moment you do this you can no longer use Qt 4.5's raster engine in
the Plasma desktop as an XPixmap is no longer a QPixmap. I keep
reading everywhere that raster engine was specifically designed with
Plasma in mind.

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

Taskbar thumbnails use the scaling filter that the user has specified
in the KWin advanced settings panel. By default it is bilinear, I
assume you want to force it to always be trilinear for thumbnails?

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

The EWMH specifications currently does not specify how to handle this.
Before this can be integrated an acceptable standard will need to be
decided upon.

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

Same as above, we need a standard to be developed before anything happens.

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

The problem with this one is that we have yet to work out an algorithm
that can expand a window mask (KWin already knows the shape of the
window so there is no need to send a separate shadow mask) that can
run faster than 15fps. If you guys can write something that works
without bringing the desktop to a crawl please let us know as it will
close a very old bug [1] that we've been trying to solve all this
time.

[1] http://bugs.kde.org/show_bug.cgi?id=157353

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

Is there any reason why we are not using KWin shadows for the panel?
If you must absolutely not use KWin shadows then having window
snapping ignore dock windows if the window sets a strut is no hard
task.

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

I agree with having the theme in desktop effects but I'm not too sure
by what you mean by the "window menu". You mean the Alt+F3 one? I
don't really see how using Plasma there will benefit anything.

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

If there is a detach button and doesn't interfere with resizing of the
sheet I have no problem with this feature. I extremely regularly move
file open/save dialogs around to see what's in the parent and resize
them so I can more quickly get to the file I want.

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

Assuming you mean "desktop" instead of "containment" then "no" for the
reasons that we have already discussed.

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

I like it. How can KWin detect if Plasma is running (So KWin can run
without Plasma) and trigger the dashboard when selected? For things
like box switch and the like we will also need a thumbnail of the
dashboard. As X doesn't create thumbnails of non-existent or unmapped
windows the dashboard will need to always be mapped and placed behind
the desktop window. Doing this will also solve the white screen issue
when the dashboard is shown.