HardyDesktopEffects

Differences between revisions 5 and 6
Revision 5 as of 2007-11-01 16:53:46
Size: 6340
Editor: 12
Comment:
Revision 6 as of 2007-11-02 15:05:19
Size: 7251
Editor: 12
Comment:
Deletions are marked like this. Additions are marked like this.
Line 22: Line 22:
 * Middle-ground between desktop-effects and ccsm
   - simple-ccsm with UI tweaks
   - port appearance capplet to use libcompizconfig so that profiles
     can be used there to save custom settings
 * Default effects changes from feedback
   - scaleaddons
   - scalefilter (+ enable case-insensitive)
   - add live-preview on extra effects for wall (in the change animation)
 * New plugins/opportunities
   - session-management plugin

 * use simple-ccsm as base for graphical configuration frontend
 * appearance-capplet has to use libcompizconfig to allow saving custom profile-settings
 * change default effects by adding scaleaddons, scalefilter (with case-insensitiveness) and live-preview for wall (during change animation)
 * new plugin for proper session-management
Line 50: Line 45:
 * Decorator
   - New one, written in C.
   - Need SVG backend.
   - Dennis mentioned:
 A window decorator could be written that unredirects the window, makes a frame window,
 and reparents the window to it's decoration. After this all painting code in compiz
 is disabled, and then you have a 2D version of Compiz that will work without
 Compiz/OpenGL (we would still need a new 2d switcher plugin).
 * write new SVG-based window-decorator
Line 59: Line 47:
 * session-management: YES! (talk to amaranth and try to get it upstream)
Line 79: Line 66:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:  * The graphical frontend for accessing plugin-settings will based on the [https://code.launchpad.net/simple-ccsm simple-ccsm] effort.

 * The appearance-capplet will have to be ported to libcompizconfig. This change will allow saving any set of plugin-settings the user might have made (using the graphical frontend [https://code.launchpad.net/simple-ccsm simple-ccsm]) as a custom profile. That custom profile will then be used when the user switches between effects-levels (none, normal, extra, custom) in the appearance-capplet.

 * A new window-decorator needs to be written in C, which sports a SVG-backend. To prototype this new decorator it is agreed to write it in python first to gather experience of what is needed from a functionality standpoint. According to [mailto:onestone@kemper.freedesktop.org Dennis "onestone" Kasprzyk] this new window-decorator could be written in a way so that it unredirects the window, makes a frame window and reparents the window to it's decoration. After this all painting code in compiz is disabled, and then you have a 2D version of Compiz that will work without Compiz/OpenGL (we would still need a new 2d switcher plugin).

 * A new plugin for proper session-management needs to be written (Travis "amaranth" Watkins). This will be enabled for the normal and extra effects-levels.

 * Add scaleaddons and scalefilter (+ enable case-insensitive) to the normal effects-level. Add live-preview for wall (in the change animation) to the extra effects-level.
Line 91: Line 86:
Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.
 * The only current migration action that needs to happen is, if the user is running the custom effects-level. During or after the update to the new release (from feisty to hardy) some one-time script needs to generate a libcompizconfig profile of the users plugin-settings and save that as the "custom" profile. This is probably best hooked up in a configure-step of the package-install.
Line 98: Line 90:
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.

This need not be added or completed until the specification is nearing beta.
(This need not be added or completed until the specification is nearing beta.)
Line 104: Line 94:
 * redirected direct rendering (OpenGL-apps not working properly unter compiz, if run on system using DRI-based drivers... that means all OpenSource-drivers at the moment)  * redirected direct rendering (OpenGL-apps not working properly unter compiz, if run on system using DRI-based drivers... that means all OpenSource-drivers at the moment) the ongoing work on DRI2 will automatically fix this, it is not certain that will be ready for the Hardy-cycle

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

  • Launchpad Entry: hardy-desktop-effects

  • Packages affected: compiz, compiz-core, compiz-plugins, compiz-fusion-plugins-main, compiz-fusion-plugins-extra

Summary

  • Top compiz bugs
    • - Listen to changes for RandR configuration. New displays/new sizes/rotations.
  • Xorg/driver related bugs
  • Compiz 0.7
    • - Not sure if we can rely on 0.7 as of now. However 0.6 will likely not be actively maintained
      • will have to contact David, to find out. This is not overly important to decide on now.
      - Large parts of core are being rewritten. Using object system. - XRender output, ability to run without OpenGL, but requires accelerated 2d video
      • -> should be as fast/slow as metacity

      - we need to check if 0.7 is better than 0.6 basicly, as there is currently
      • not a lot of new stuff (it seems to be at least)
  • use simple-ccsm as base for graphical configuration frontend
  • appearance-capplet has to use libcompizconfig to allow saving custom profile-settings
  • change default effects by adding scaleaddons, scalefilter (with case-insensitiveness) and live-preview for wall (during change animation)
  • new plugin for proper session-management
  • Expose compiz keyboard shortcuts in UI (gnome-keyboard-shortcuts?)
  • Less insane compiz shortcuts
    • - remove everything and put back only important ones - add them to the gnome-keybinding propoerties capplet (compiz-keys.xml) - Standardize on use of super key as a binding. - Allow super key to be changed out for another key.
  • Review compiz use of shortcuts to make consistent
    • - Super key.
  • Compiz shortcuts should work after purging metacity
  • make compiz features more discoverable:
    • - hotcorners with a modifier (?) - window manager menu with additional compiz features - have a menu on the workspace switcher that exposes
      • functionality (scale, expose) + the keybindings
      - Display shortcuts where users are likely to look for them. i.e. when right
      • clicking on pager shows keybindings for move viewport, expo, so on, so forth.
  • fix the problem that when metacity is purged the keybindings break
    • (integration mode should write both compiz and metacity settings)
  • write new SVG-based window-decorator
  • we have issues with multihead

Release Note

Run compiz as the default compositing/window-manager on supported graphics-hardware.

Rationale

Running compiz (as default instead of metacity) is meant to be as smooth and non-intrusive as possible, while improving the visual appeal and accessability of the default desktop-setup. The user should only recognize the improved visual appeal and added usability-improvements on the desktop. There should be as little breakage as possible moving from metacity to compiz in terms of behaviour, keyboard-shortcuts and themes.

Use Cases

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

  • The graphical frontend for accessing plugin-settings will based on the [https://code.launchpad.net/simple-ccsm simple-ccsm] effort.

  • The appearance-capplet will have to be ported to libcompizconfig. This change will allow saving any set of plugin-settings the user might have made (using the graphical frontend [https://code.launchpad.net/simple-ccsm simple-ccsm]) as a custom profile. That custom profile will then be used when the user switches between effects-levels (none, normal, extra, custom) in the appearance-capplet.

  • A new window-decorator needs to be written in C, which sports a SVG-backend. To prototype this new decorator it is agreed to write it in python first to gather experience of what is needed from a functionality standpoint. According to [mailto:onestone@kemper.freedesktop.org Dennis "onestone" Kasprzyk] this new window-decorator could be written in a way so that it unredirects the window, makes a frame window and reparents the window to it's decoration. After this all painting code in compiz is disabled, and then you have a 2D version of Compiz that will work without Compiz/OpenGL (we would still need a new 2d switcher plugin).

  • A new plugin for proper session-management needs to be written (Travis "amaranth" Watkins). This will be enabled for the normal and extra effects-levels.
  • Add scaleaddons and scalefilter (+ enable case-insensitive) to the normal effects-level. Add live-preview for wall (in the change animation) to the extra effects-level.

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

  • The only current migration action that needs to happen is, if the user is running the custom effects-level. During or after the update to the new release (from feisty to hardy) some one-time script needs to generate a libcompizconfig profile of the users plugin-settings and save that as the "custom" profile. This is probably best hooked up in a configure-step of the package-install.

Test/Demo Plan

(This need not be added or completed until the specification is nearing beta.)

Outstanding Issues

  • redirected direct rendering (OpenGL-apps not working properly unter compiz, if run on system using DRI-based drivers... that means all OpenSource-drivers at the moment) the ongoing work on DRI2 will automatically fix this, it is not certain that will be ready for the Hardy-cycle

  • the current migration of workspace-layout from metacity to compiz is a unpleasant workaround, because the number of rows of the workspaces under metacity is a property of the wnck-applet and not metacity... after speaking with upstream the [http://standards.freedesktop.org/wm-spec/wm-spec-latest.html EWMH-spec] needs to be extended to make this cleaner in the future

BoF agenda and discussion

Sander Smid: Perhaps add AWN as the launcher / taskbar replacement since they now support applets. More info at http://wiki.awn-project.org/index.php?title=Main_Page (demo at: http://awn.wetpaint.com/page/Demo)

Mirco Müller: AWN will not be a default panel- or taskbar-replacement for Hardy. But it would be reasonable to have it available in universe, thus people who want it can install it easily. Maybe if interested developers push hard for it (to make it a solid alternative to the gnome-panel... I honestly don't know how well it is tested atm) it could be considered for Hardy+1. As a hint for the future, Sander, if you want to see this discussed in a thorough fashion during an Ubuntu Developer Summit create a spec for it. The wish to replace gnome-panel with awn, which is what I assume you imply, isn't something that is easily changed. A lot of thought needs to go into something like this, if you want to change installed defaults.


CategorySpec

DesktopTeam/Specs/HardyDesktopEffects (last edited 2008-08-06 16:31:28 by localhost)