[Panel-devel] My desktop thoughts

Hans Oischinger hans.oischinger at h3c.de
Sat Aug 20 18:50:08 CEST 2005


Currently the desktop is no more than an icon view that displays the contents 
of ~/Desktop. The Plasma website already outlines how this is gonna change, 
but I want to go into detail a bit more here, especially when it comes to the 
stuff that I'm most interested in :)

Awareness of what's happening on the desktop's surface
-------------------------------------------------
The Desktop is a simple container for plasmoids, it is however aware of the 
applications and windows on top of it and can react passively by aligning 
plasmoids around the currently selected window, showing some plasmoids only 
when specific apps are running and similar funky stuff.

That was short, the next one is the central point of my plan and therefore a 
bit longer as it also needs to be explained a little more.

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.
- 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 took the example of KScreensaver, but there are others having these issues 
like Superkaramba and of course also my next topic :)

Wicky windows :)
-------------
Well, everybody wants to see MacOSX-like eye candy, especially exposé and a 
nicer (and much saner) "show desktop functionality".

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.
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.

So essentially we don't need kompmgr, which would also have to transform 
XEvents to the transformed windows, for 2 seconds of fun! 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".

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.

That would also easily allow plasmoid-aware window management as described 
here:
http://kde-artists.org/main/component/option,com_smf/Itemid,48/expv,0/topic,254.0

Back to the desktop
-------------------
There are some non-KDE applications painting on the desktop via RootPixmap(), 
but with plasma we shall have replacements for root-tail and if you want so 
even xeyes or xsnow :). Even mplayer could be QXEmbedded into a plasmoid.
So I propose that all rootwindow painting code goes where it belongs, that is 
the desktop plasmoid and nowhere else.


Criticism is welcome and also anticipated ;)
-------------- 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/ea7673f6/attachment.pgp


More information about the Panel-devel mailing list