SpitAndPolish
Summary
GTK+ supports RGBA-colormaps, which allow to improve the aesthetic looks of the UI, especially in combination with a composited environment (e.g. compiz, metacity with enabled compositor). RGBA-colormaps make it possible to composite child-widgets against their parents background. In addition to that it is also possible to composite top-level windows against the desktop or whatever window is stacked below it, if run under a composited environment. There are two common approaches to make use of this GTK+-feature. The first one is a GTK+-theme engine (e.g. murrine) drawing widgets by default with a RGBA-colormap and choose the opacity on a per-widget-basis. The most popular variation of this - under composited environments - is to have the top-level windows background to be slightly transparent (see screenshot A). The second approach, which also works without a RGBA-capable GTK+-theme, is to manually take care of the clearing and filling of a widgets background in its expose-handler (see screenshots B, C and D).
screenshot A (GTK+-theme-engine murrine with RGBA-support)
screenshot B (top-level window composited against desktop)
screenshot C (top-level window composited against desktop)
screenshot D (buttons composited against window-background)
This spec does not have a targetted release of Ubuntu and should rather be viewed as an on-going effort to improve the looks of the desktop in general. Not all mentioned improvements of UI-elements need to be implemented at once, although it would be nicer from a consistency point of view.
Release Note
Decoration-less popup-dialogs now use slightly rounded corners and subtle transparencies in order to make them visually more pleasing and provide a more consistent look in regards to enabled desktop-effects. Main application windows also have very light transparencies now as long as the application does not override this with custom drawing. These visual effects are only active, if desktop-effects are turned on. Also menus and comboboxes use slightly rounded corners to help unify the look of UI-elements.
Rationale
Unification of UI-elements across the desktop needs to be continued. Offering theme-artists and UI-designers greater flexibilty, makes their work more fun thus more productive. Increasing the visual attractiveness of the GNOME- and Ubuntu-desktop is of paramount importance, because users demand and expect good looking desktop-systems these days. Furthermore we need to stay competitive with offereings form other projects and vendors.
Use Cases
A list with dialogs and widgets that should make use of visual enhancements possible due to the use of RGBA-colormaps and a composited desktop (desktop-effects):
mockup of gnome-screensaver's unlock-dialog (already partly implemented)
mockup of GTK+-widget menu
mockup of GTK+-widget combobox
mockup of libgksu's authenticate-dialog (already implemented)
mockup of gnome-session's logout-dialog (already implemented)
Design
There are three sections to address. First there are the decoration-less dialogs, which should be drawn with rounded corners - using roughly the same corner-radius as buttons of the set GTK+-theme do - and a slight transparency in the dialogs background. Then there is the GTK+-theme that needs to make use of RGBA-colormaps, thus a theme-artist can make consistent use of transparencies for certain widgets and application-developers can more easily handle RGBA-drawing without needing to do the needed boiler-plate code themselves. Lastly there are a few GTK+-widgets that need to be adjusted in the way they draw themselves to avoid visual glitches when rendered with RGBA-colormaps on non-opaque backgrounds.
Implementation
Decoration-less dialogs
Good examples for decoration-less dialogs are the unlock-dialog of gnome-screensaver, the logout-dialog of gnome-session and the authenticate-dialog of libgksu. The general approach here is to...
- test if composited is available in the initialization part of the dialog
- set a rgba-colormap for the main dialog-background
- only if those two were successful connect a custom handler to its expose-event
- increase the border-width of the corresponding widget a bit
- in the custom expose-handler clear the background to fully be transparent
- get the themes background-color of the normal-state of a widget
use that to draw a non-opaque rectangle with rounded corners (yay for cairo!
- draw your own drop-shadows, since neither compiz nor metacity (with enabled compositor) do that in this case
- enjoy the new looks
This already works very well with the logout-dialog of gnome-session and the authenticate-dialog of libgksu. The unlock-dialog of gnome-screensaver is displayed on its own screen and is usually not composited. Therefore the proposed looks of the mockup above are not easily implemented and require some more work. For the moment only a plain RGB-colormap is used and the the rounded corners are achieved by clearing to opaque black and drawing on top of that.
GTK+-theme
The most complete (only) RGBA-enabled GTK+-theme-engine at the time of this writing is murrine (see screenshot A). While murrine itself does not need much more work, a freedesktop specification and a related tool need to be addressed before an engine like murrine can use RGBA-colormaps by default without any issues.
The freedesktop-specification for tray-icons needs to be updated according to the proposal published here.
Once that's in place the GTK+-widget GtkStatusIcon has to be updated to reflect those changes in the updated freedesktop-specification for tray-icons.
The second issue needing attention is a graphical configuration tool for all the options and features murrine offers. Editing gtkrc files by hand isn't a very creative way for theme-authors and artist to create new looks for theme-engines. Therefore a solid GUI frontend with decent preview-functionality has to be written. There is a first effort going in that direction available here.
GTK+-widgets
If widgets are drawn (composited) on top of non-opaque parent widgets, visual glitches are exposed in some cases due to the way certain widgets are drawn right now by upstream GTK+ and an RGBA-enabled theme-engine. For...
... you can see in the screenshot below how unaltered rendering of GtkEntry-widgets (on the left) exposes ugly non-transparent areas in the surrounding frame, while a fixed way of rendering the GtkEntry-widgets (on the right) correctly removes these opaque parts in the frame.
The approach to this fix consists of a small patch in murrine's RGBA-related drawing-code for a GtkEntry-widget and redirecting the GtkEntry to an offscreen-buffer, clearing its background to be fully transparent in its expose-handler and finally compositing it onto the parent widget in the parent widgets expose-handler. In screenshot B you see that this also works with irregular backgrounds of the parent widget.
The visual glitch shown for GtkEntry is also exposed with...
... but the approach used for GtkEntry to fix the rendering issue does not work in this case, because GtkComboBoxEntry draws itself differently. How to fix it for GtkComboBoxEntry has yet to be figured out fully.
In addition to fixing the visual glitches for GtkEntry and GtkComboBoxEntry the rendering of any kind of menu should be altered to allow slightly rounded corners - with matching drop-shadows - as well.
These widgets should be rendered like show in the screenshot-mock up here.
Migration
There will most certainly be legacy (GTK+-based) applications, which will crash or break in some kind of way, if RGBA-colormaps become the new default colormap of the used GTK+-theme. These need to be identified and fixed as soon as Ubuntu is able to ship a beta of a RGBA-enabled GTK+-theme. Those applications then need to be fixed upstream one at a time. Should the application in question be closed source its users have to switch back to a non-RGBA GTK+-theme. Or we could provide a wrapper start-script that could be used to disable the use of RGBA-colormaps by default, when such closed source legacy applications are started via the applications-menu.
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 testing, and to show off after release.
This need not be added or completed until the specification is nearing beta.
DesktopTeam/Specs/SpitAndPolish (last edited 2008-08-06 16:40:29 by localhost)