HardyDesktopEffectsProfiles

Revision 1 as of 2007-12-17 04:17:53

Clear message

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.

Summary

To avoid loosing a custom set of enabled plugins and plugin-settings compiz needs to support profiles. This support has to be provided via libcompizsettings. In addition to that profile-support will simplify the task of tweaking the other two sets of effect-levels "normal" and "extra", which can be implemented as two additional profiles. In the end changing an effect-level will just select a different profile.

See also:

Release Note

Once a user has selected the "Custom" effect-level and made changes to the set of enabled plugins and their settings via the dedicated frontend, s/he is now able to switch back and forth between any of the four possible effect-levels "None", "Normal", "Extra" and "Custom" without loosing any settings done for the "Custom" effect-level.

Rationale

It is unacceptable to have a user loose their made set of enabled plugins and plugin-settings. This is against Ubuntu's principle to always respect and preserve a users made preferences.

Having support for profiles storing a list of enabled plugins and their settings makes future tweaking of the "Normal" and "Extra" effect-levels easier for Ubuntu-developers.

Use Cases

  • Sam had a graphics-card failure and had to replace his powerful pixel-pushing beast with less capable one. He used a custom set of plugins and settings for "Visual Effects". For the meantime - until he gets a new powerful graphics-card - he needs to switch back the effect-level for the less capable graphics-card to be able to run a composited desktop still. Once he get the new graphics card he will be easily able to switch back to his custom settings with just one mouse-click.
  • Petra considers herself to be a power-user and tweaker. Not content with the shipped set of effect-levels "Normal" or "Extra" she creates her own custom one. When she gets a new additional computer, she wants to simply copy her settings for "Visual Effects" in order to avoid making the changes all over again on the new machine.

Assumptions

simple-ccsm is expected to be compliant with the GNOME-HIG and act as the replacement for ccsm.

Design

simple-ccsm is meant to be the dedicated frontend for creating and changing profiles. In order to do so simple-ccsm has to use libcompizsettings to load and save profiles.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

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

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.

Test/Demo Plan

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.

Outstanding Issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec