HardyDesktopEffects

Differences between revisions 8 and 12 (spanning 4 versions)
Revision 8 as of 2007-11-02 17:06:20
Size: 10054
Editor: 12
Comment:
Revision 12 as of 2007-11-27 13:40:45
Size: 11552
Editor: dslb-084-063-116-058
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from HardyDesktopEffects
Line 31: Line 32:
   - I'm opposed to this, as not all computers have a Super key (many laptops, for example)
Line 55: Line 57:
A user switching from metacity to compiz (e.g. updating from Dapper/6.06 LTS to Hardy/8.04 LTS) will expect all learned keyboard-shortcuts from metacity to result in the same behaviour under compiz. Users switching from metacity to compiz (e.g. updating from Dapper/6.06 LTS to Hardy/8.04 LTS) will expect all learned keyboard-shortcuts from metacity to result in the same behaviour under compiz. It would alienate people, if they were required to learn new keyboard-shortcut to perform the same actions or if known keyboard-shortcuts would no longer result in the same behaviour.
Line 57: Line 59:
plugins... People who are upgrading from Ubuntu 7.10 to 8.04 will expect their settings for compiz to be preserved.

The session-management users of Dapper 6.06 are used to, has to work the same way under compiz. This is a functionality that must not be dropped!

At the time users recognize the improved desktop-rendering (provided via compiz), they naturally become curious and want to investigate its additional features. These have to be "handed" to them in the most simple way possible, without them being required to read any manuals or web-forums in order to get to know new functionality.

New features of the underlying Xorg should not cause compiz to crash or switch off (fallback to metacity). It has to be made sure that additional functionality provided via RandR (monitor-hotplugging, screenrotation) does not break the compiz-rendered desktop.

More technical users, who wish to tweak specific properties or behaviours of compiz, would expect a streamlined graphical-frontend for doing so, due to the integrated nature of compiz into the desktop. Forcing them to something like gconf-editor would cause a break in terms of UI-integration and therefore has to be avoided.
Line 61: Line 71:

Line 62: Line 74:

Line 101: Line 115:

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 [mailto:davidr@novell.com David Reveman], 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
  • write new SVG-based window-decorator
  • less insane compiz-shortcuts
  • expose the compiz-shortcuts in gnome-keyboard-properties (compiz-keys.xml)
  • only one modifier-key for triggering compiz-functions (Super-key will be the default)
    • - I'm opposed to this, as not all computers have a Super key (many laptops, for example)
  • 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)
  • 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.

New compiz features (additions over metacity) should be more discoverable for users. Aside from that compiz should really behave just like metacity from a keyboard-shortcut point of view.

Use Cases

Users switching from metacity to compiz (e.g. updating from Dapper/6.06 LTS to Hardy/8.04 LTS) will expect all learned keyboard-shortcuts from metacity to result in the same behaviour under compiz. It would alienate people, if they were required to learn new keyboard-shortcut to perform the same actions or if known keyboard-shortcuts would no longer result in the same behaviour.

People who are upgrading from Ubuntu 7.10 to 8.04 will expect their settings for compiz to be preserved.

The session-management users of Dapper 6.06 are used to, has to work the same way under compiz. This is a functionality that must not be dropped!

At the time users recognize the improved desktop-rendering (provided via compiz), they naturally become curious and want to investigate its additional features. These have to be "handed" to them in the most simple way possible, without them being required to read any manuals or web-forums in order to get to know new functionality.

New features of the underlying Xorg should not cause compiz to crash or switch off (fallback to metacity). It has to be made sure that additional functionality provided via RandR (monitor-hotplugging, screenrotation) does not break the compiz-rendered desktop.

More technical users, who wish to tweak specific properties or behaviours of compiz, would expect a streamlined graphical-frontend for doing so, due to the integrated nature of compiz into the desktop. Forcing them to something like gconf-editor would cause a break in terms of UI-integration and therefore has to be avoided.

Assumptions

Design

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 [https://code.launchpad.net/libcompizconfig 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 (it is strongly advised to use [https://code.launchpad.net/librsvg librsvg] here). 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 ([mailto:amaranth@ubuntu.com 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.
  • The default set of compiz keyboard-shortcuts has to be stripped down to the bare minimum. The starting point for this is the set users know from metacity. The shortcuts have to be exposed in gnome-keyboard-properties. A XML-file is used for populating the list of keyboard-shortcuts in gnome-keyboard-properties. The default "compiz modifier" will be the Super-key. A user will only be able to change the Super-key to another key (e.g. Ctrl, Alt etc) but not introduce new multi-modifier keyboard-shortcuts. That is meant to avoid mapping conflicts with shortcuts used in applications. The use of shortcuts used by compiz needs to be consistent across all compiz core-features and plugins.
  • The compiz-shortcuts need to be protected from a possible purge of metacity-shortcuts in gconf. This could be solved by writing compiz- and metacity-shortcut-settings at the same time in integration-mode (what is that mode actually?).
  • The provided features and plugins of compiz need to be made more discoverable. Triggering functions via hotcorners are meant to be bound to the "compiz-modifier" (this is the Super-key by default). So when pressing the modifier the configured hotcorners should "lighten up" to give the user a visual clue that they are now able to trigger a hotcorner-function (e.g. trigger the expo- or scale-plugin). The window-menu of the decoration has to list the most commonly used compiz-functions

UI Changes

  • The graphical frontend for manipulating the custom effects-level will be changed from ccsm to simple-ccsm. We need to make sure that simple-ccsm complies with the GNOME-HIG.
  • gnome-keyboard-properties will be the place to advertise the new default compiz-shortcuts users can use.
  • the window-menu of the new window-decorator will have to be extended to yield the commonly used compiz functions
  • wnck-applet of gnome-applets will need to dynamically adapt its context-menu UI (the right-click menu) in order to display shortcuts for compiz when compiz is running (e.g. move between viewports, trigger expo-plugin, trigger scale-plugin)

Code Changes

  • compiz
  • gnome-keyboard-properties (part of gnome-control-center)
  • gnome-appearance-properties (part of gnome-control-center)
  • simple-ccsm

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 does not work with the current implementation of the DRI-drivers (free, OpenSource drivers). The on-going work regarding [http://wiki.x.org/wiki/DRI2 DRI2] will automatically fix this. It is certain that this will not be ready for the Hardy-cycle. The only solution to speed this up is providing [mailto:krh@bitplanet.net Kristian Høgsberg], the main developer behind this effort, with a set of helping hands implementing all the needed parts. It has to be regarded as a regression of functionality especially for people who will move from Ubuntu 6.06 LTS to Ubuntu 8.04 LTS. While OpenGL-based applications worked flawlessly for them with Ubuntu 6.06 LTS they will not work glitch-free under Ubuntu 8.04 LTS.

  • 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)