[Panel-devel] My desktop thoughts

[Hans Oischinger]

> >   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.
I wasn't talking about unmapped pixmaps. When some apps do root-window 
painting they paint on the root pixmap, over the stuff that is currently on 
the desktop and therefore make it impossible to retrieve these underlying 
desktop contents. Two apps sharing one pixmap :(

>
> > - 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.
The screensaver has no own widget in this context. Maybe I chose a really bad 
example. I don't mean screensavers as usual but screensavers that were told 
to draw on the rootWin (there is a console parameter for this)

> > 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.
Hehe, I suspected that you got something running doing this.

>
> > 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.
Uhm, let's say the widget is scaled to 1/2 size via XRender, wouldn't the 
compositing manager need to transform mouse input events in the same way... I 
remember having played around with XRender transformations in kompmgr and all 
mouse events were received in the wrong place... well, maybe my mind is 
playing tricks on me, you'll definately know better ;)

> > 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! :)
Well, I'm not so sure about the kompmgr right now.
1. There is currently no IPC mechanism that I could use to tell the composite 
manager that it should make all windows fly out of the screen.
2. The current design isn't even Qt dependant, nor OOP, and there have been 
quite some doubts about how it performs implemented in this way.

What I have in mind here is preventing the kompmgr from bloat because of some 
short animations (Yes, I really care for litle kompmgr :) )

Have you already experimented with a composition manager with IPC?
Every manager I've seen until now is based on Keith Packard's good old proof 
of concept xcompmgr.

> > 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.
Still you would need to communciate between both.
But I agree that a seperation between both would be nice and worth it.
Still you could easily convince me to scrap all I wrote here by showing me a 
qt based kompmgr :)

Greets,
	Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20050820/9fe435bf/attachment.pgp