Plasma/TakingAdvantageOfCompositing: Difference between revisions
No edit summary |
Mgraesslin (talk | contribs) |
||
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 == |
Revision as of 17:28, 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