[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