Re: Theme patriation

["Robert Staudinger" <robert staudinger gmail com>]

On Sun, Oct 26, 2008 at 11:38 PM, Thomas Thurman <tthurman gnome org> wrote:
> Several people have raised the idea recently that the responsibility for
> drawing window borders might better lie with the application than the
> window manager.  The idea goes something like this:
>
>  1. The window border theme parsing and displaying code should live in a
> library.  (It already does, but its ABI is allegedly private, though in
> practice Compiz binds against it anyway.  For this we will need to make
> it public.)
>
>  2. When an app creates a GtkWindow, GTK will draw the borders as
> appropriate by calling this library.
>
>  3. Metacity will set a property on the root window with a name such as
> _METACITY_DECORATION_DELEGATION to signal its willingness to delegate
> decoration.  GTK will also set a property on each window it decorates,
> with a name such as _GTK_DECORATED, so that Metacity will not attempt to
> decorate it for the second time.
>
> This would mean that the themes could interact better with the contents
> of the window.  For example, it would become easy to add a button like
> the oval button on an OS X window which hides the toolbar.  It would
> also make it much easier to allow per-app themes, as is often requested
> for the GIMP.
>
> Possibly the library could be clever enough to understand more than one
> theme format.  Eventually it would probably be best to split it away
> from Metacity entirely.
>
> Do you think this is a good plan?

Shall we not lay down the goal of the plan first?

My personal interest in this issue stems from desire for closer visual
integration between window decoration and window-"payload", One way to
achieve this would be delegating the responsibility of drawing
decorations to the toolkit (so it supports that), allowing for
`native' support of [1]-like windows and fancy blend-ins between
decoration and menu-/toolbar.

People have been pointing out various disadvantages with getting rid
of window decoration under the control of the WM (unresponsive apps,
unfavourable effects on memory consumption, ...). If that can't be
solved with the radical approach you are proposing, maybe the WM could
keep the decorations and just have the theme (in whatever form)
provided by gtk, so blend-in is possible?

The actual theme format is an orthogonal issue. From a themer's point
of view it would seem very intuitive to just theme "window" giving it
borders, background-color/-image/... and specifying border-width and
corner-rounding. Even we stick to the WM-provided decorations it would
be feasible for the WM and the toolkit to query and draw the window
part(s) it needs with the correct offset and clipping to allow for
seamless blend-in. (Maybe the gtk engine interface would need some
extension so it can tell gtk/mcity whether it supports wm-decorations
and -buttons.)

I am of course not in the position to call for deprecation of the
metacity theme format, but if anyone with WM fu was interested in
prototyping the above with gtk and css let's give it a spin.

- Rob