Jump to content

Plasma/TakingAdvantageOfCompositing: Difference between revisions

From KDE Community Wiki
Notmart (talk | contribs)
Mgraesslin (talk | contribs)
 
(4 intermediate revisions by 2 users not shown)
Line 16: Line 16:


=== kwin ===
=== kwin ===
* Needs new layer to stack widgets between windows and desktop.
* Needs new layer to have the dashboard on top of all windows. Between Fullscreen/Keep Above and Screensaver
* Two new window types _KDE_WM_WINDOW_TYPE_WIDGET and _KDE_WM_WINDOW_TYPE_DASHBOARD might be useful
* Global Shortcuts could be blocked when dashboard is active if there is a window type
* Wallpaper could be used in effects currently showing black background (e.g. Present Windows on Netbook Shell)
* Wallpaper could survive Plasma crash
* Maybe move complete Wallpaper rendering code into KWin?


== Tooltips as Textures ==
== Tooltips as Textures ==
Right now tooltips are normal windows, this makes moving and resizing them rather inefficient.
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
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
Probably a new effect in kwin is needed to provide the tooltips. It could use an EffectFrame for the background and could use the normal TaskbarThumbnail effect to render windows on top of it. More hooks in KWin are needed to set Icon and text. Probably best is if KWin uses the existing thumbnail layouting code and renders to a texture. When something changes KWin could render to a new texture and crossfade between them.


== Centralized Screen Edge Triggers ==
== Centralized Screen Edge Triggers ==
Best moved into KWin. KWin already has the code for it, it just needs to be refactored and made more generic. We need to define what Plasma needs from KWin and whether it makes sense to have a more generic screen edge handling (e.g. triggering anything what is available to DBus)
== Panel Featuers As Effects ==
Would allow KWin to stack the shadow correctly. All the required features listed in this page show that KWin needs to integrate textures/effect frames into the stacking order on compositing. This needs some refactoring (maybe GSoC project). Fast solutions are nevertheless possible.
=== Hidden Panel Glow ===


== Panel Glow ==
=== Panel Shadow from Svg ===

Latest revision as of 17:38, 20 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

  • Needs new layer to stack widgets between windows and desktop.
  • Needs new layer to have the dashboard on top of all windows. Between Fullscreen/Keep Above and Screensaver
  • Two new window types _KDE_WM_WINDOW_TYPE_WIDGET and _KDE_WM_WINDOW_TYPE_DASHBOARD might be useful
  • Global Shortcuts could be blocked when dashboard is active if there is a window type
  • Wallpaper could be used in effects currently showing black background (e.g. Present Windows on Netbook Shell)
  • Wallpaper could survive Plasma crash
  • Maybe move complete Wallpaper rendering code into 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

Probably a new effect in kwin is needed to provide the tooltips. It could use an EffectFrame for the background and could use the normal TaskbarThumbnail effect to render windows on top of it. More hooks in KWin are needed to set Icon and text. Probably best is if KWin uses the existing thumbnail layouting code and renders to a texture. When something changes KWin could render to a new texture and crossfade between them.

Centralized Screen Edge Triggers

Best moved into KWin. KWin already has the code for it, it just needs to be refactored and made more generic. We need to define what Plasma needs from KWin and whether it makes sense to have a more generic screen edge handling (e.g. triggering anything what is available to DBus)

Panel Featuers As Effects

Would allow KWin to stack the shadow correctly. All the required features listed in this page show that KWin needs to integrate textures/effect frames into the stacking order on compositing. This needs some refactoring (maybe GSoC project). Fast solutions are nevertheless possible.

Hidden Panel Glow

Panel Shadow from Svg