KWin and Plasma integration

[Sebastian Kügler]

Since we're entering the fun-phase for KDE 4.2, I thought it would be a good 
idea to share some ideas I have about Plasma and KWin integration. One design 
goal would be to have some tooling in Plasma that exposes certain KWin effect 
to Plasma. I'm thinking of the following basic use cases here:

- previews of windows (as with the taskbarthumbnails)
- effects for Plasma (e.g. zooming of the ZUI, animations for Plasma windows 
  (such as Dashboard or tooltips)

I need to note here that I have a serious lack of knowledge about X11 
internals and window managing. I did *some* polishing on KWin effects, so I 
have at least basic understanding of how the KWin effects work.

The mechanic is usually that a kwin effect gets passed a window and then 
decides, based on method calls such as effectwindow->isToolTip() or 
effectwindow->isMainWindow() what to do with the window. This way, you can, 
for example apply window transformations only to the Desktop.

Right now, we have window previews in tooltips, but it's not *really* nice. 
The tooltips are using xembed to put the window into the tooltip. The problem 
is that the fading in of the tooltip is not in sync with the windowpreview 
(which doesn't 

So how to make certain applet animations use the Dashboard?

(1) Hacks: Using the existing windowtypes known in EffectWindow
(2) A KWin Plasma effect: a plugin that 'collects' some basic effects
(3) Extending EffectWindow in some way to we can set some property of it, and 
    then add checks for this windowtype in certain plugins.

(1) is quite fragile, and hackish, bah
(2) would mean duplicating or at least writing our own effects, and probably 
    put more than one effect into a plugin.

I think the easiest way would be (3). That would mean when the Plasma 
Dashboard appears, the fade in effects has

if (w->isPlasmaDashboard()) {
	// code to scale in the window
	...
}

in it, and Dashboard window is set to be a PlasmaDashboard (or somesuch). This 
should leave sideeffects pretty much out of the way. I'm not sure how the API 
for that would look like. In EffectWindow, every window type has a function 
corresponding to it. So if we decide that we need another animation type, we 
need to extend the EffectWindow API *and* add the implementation in the 
relevant effects.

That's what I can make of it. More food for thought than anything concrete 
right now (or even code!), so feel free to ignore it. Better yet, share your 
thoughts.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080719/7b203a70/attachment.pgp