--===============0296335915==
Content-Type: multipart/signed;
  boundary="nextPart2321706.v24XrYnWLv";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2321706.v24XrYnWLv
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> >   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=20
painting they paint on the root pixmap, over the stuff that is currently on=
=20
the desktop and therefore make it impossible to retrieve these underlying=20
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 b=
ad=20
example. I don't mean screensavers as usual but screensavers that were told=
=20
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=E9. In Expos=E9 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=E9 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=20
compositing manager need to transform mouse input events in the same way...=
 I=20
remember having played around with XRender transformations in kompmgr and a=
ll=20
mouse events were received in the wrong place... well, maybe my mind is=20
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 composi=
te=20
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=
=20
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 so=
me=20
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 proo=
f=20
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=20
qt based kompmgr :)

Greets,
	Hans

--nextPart2321706.v24XrYnWLv
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.9.18 (GNU/Linux)

iD8DBQBDB3phxj5iiDKg1wQRAkElAKCOgpRF8zaBj4g6nPc1d3r/OKIL0gCfYnR0
394Yq91K3fSzaVN0WfHrzeg=
=5g9r
-----END PGP SIGNATURE-----

--nextPart2321706.v24XrYnWLv--

--===============0296335915==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel

--===============0296335915==--