[Panel-devel] My desktop thoughts

[Zack Rusin]

On Saturday 20 August 2005 18:50, Hans Oischinger wrote:
> Provide the ability to react to external calls
> ----------------------------------------------
> KScreensaver has the ability to draw on the root window (which is the
> desktop) in a very hacky way through some X calls. But there are some
> problems with that:
> - Transparency is a no-go as you can't access the desktop contents
> when you're painting over them.
>   Even with COMPOSITE there is no way to acces those as the backing
> pixmap gets unusable, too.

Pixmaps get invalidated only when a window is unmapped. In my window 
manager instead of unmapping windows I was just stacking them under the 
desktop, which of course leaves their contents in tact (and allows me 
to have fully updated previews in the taskbar-like-application) but 
wastes some memory.

> - KDesktop doesn't know when painting occurs on top of it occurs and
> this leads to uglyness like:
>   The screensaver exits and kdesktop doesn't know that it should
> repaint, leaving parts of the screensaver on the desktop, causing
> uglyness. - Multiple applications painting on the desktop interfere
> with each other and cause uglyness, too

I'm not sure if I follow, why would kdesktop need to know that a widget 
that's above it needs a repaint? That widget should just repaint 
itself.

> This is stuff that is not covered by the COMPOSITE manager, at least
> not with it's current design. If there are already plans and ways
> that make this stuff possible with kompmgr, please enlighten me.

Well yeah, I'm doing that in my composition manager. You just paint the 
pixmaps any way you want to.

> But actually we don't need and imo even desire to let kompmgr do this
> stuff because we don't actually want to transform the windows in
> let's say Exposé. In Exposé you don't have scaled windows, you have a
> scaled representation of your windows in form of a screenshot. The
> windows themselves are unmapped at this time. We just need a short
> animation, that zooms into the Exposé view. Same thing for "Show
> desktop": You press "Show desktop" and all the windows slide out of
> your screen. The windows are unmapped here, too and we just want a
> nice animation for unmapping.

Well, there's a number of problems with this approach. 

> So essentially we don't need kompmgr, which would also have to
> transform XEvents to the transformed windows, for 2 seconds of fun!

Why would it do that? Composition managers just compose pixmaps, that's 
all they do.

> All we need for those window effects are the backing pixmaps of all
> windows (given to us by COMPOSITE) and an area we can paint onto. The
> latter is "the desktop".

I'm not sure whether you realize it but you're just describing how 
composition manager works. That piece of software which paints those 
windows on "the desktop" is the composition manager. So basically what 
you're saying is: we don't need composition manager, all we need is a 
composition manager! :)

> Of course all these window effects belong into kwin's interface. My
> proposal means however that kwin only forwards the "showdesktop"
> calls, via dcop, to the desktop, which is responsible for the
> painting.

I don't think I agree with your argumentation here. I'm not a big fan of 
embedding composition manager in the window manager at the moment. I'd 
like to have window manager do window managment and composition manager 
doing paintaing. There's a few reasons for that, for plasma the most 
interesting one is that with coming of Xgl one needs to be able to 
switch from the normal XRender based composite manager to a more 
advanced GLX based composite manager and if they're embedded into 
window manager you need to switch that as well.


Zack


-- 
I intend to live forever, so far so good.