Plasma and KWin Integration

[Jud Craft]

I would suggest that you also please look at integrating window
grouping between Plasma's tasklist and with Kwin, as mentioned in a
post earlier.

http://lists.kde.org/?l=kwin&m=123257671807508&w=2

I apologize if inappropriate, but I thought it would be an excellent
example of Plasma-Kwin integration, if task integration is a path the
admins wish to take.

Also, on your #10:  Don't you mean, "so users without _mice_ can
activate and use them"?

On 2/9/09, 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).
>
>
> 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?
>
> 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'.
>
>
> 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.
>
>
> 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?
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> 9. Hide the panel when zooming out to show the containments.
>
> As discussed already by Sebas, and patch provided.
>
>
> 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.
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>