Jump to content

Plasma/TakingAdvantageOfCompositing: Difference between revisions

From KDE Community Wiki
Aseigo (talk | contribs)
Notmart (talk | contribs)
Line 18: Line 18:


== Tooltips as Textures ==
== Tooltips as Textures ==
Right now tooltips are normal windows, this makes moving and resizing them rather inefficient.
if kwin would directly render the tooltip texture on screen, it would be possible to have smooth resize, move and fade of tooltips on screen


== Centralized Screen Edge Triggers ==
== Centralized Screen Edge Triggers ==


== Panel Glow ==
== Panel Glow ==

Revision as of 21:40, 15 December 2010

These are all (possible!) ideas that could be implemented to improve the state of the Plasma Workspaces by using KWin's compositing technologies more aggresively and creatively.

We'll need to keep the existing fallbacks in place to preserve the non-composited case. This would augment those fallbacks.

Wallpaper Separate From DesktopView

If the wallpaper is redirectable (rather than painted on the Containment itself), then the DesktopView can be used as the DashboardView, fading between wallpapers can be moved out of the wallpaper plugins, wallpapers won't need to repaint themselves just because widgets move over them, etc.

libplasma

  • Applet::paint(..) is where the wallpaper painting is triggered. Containment needs a way to be told (or to detect on its own) when it should redirect and to where.

plasma-desktop

  • DesktopView should not create a DashboardView unless the necessary KWin support is unavailable. It should instead trigger the creation of a surface that the wallpaper will paint to that KWin would then manage as the background.

kwin

Tooltips as Textures

Right now tooltips are normal windows, this makes moving and resizing them rather inefficient. if kwin would directly render the tooltip texture on screen, it would be possible to have smooth resize, move and fade of tooltips on screen

Centralized Screen Edge Triggers

Panel Glow