On Sun, Oct 26, 2008 at 11:38 PM, Thomas Thurman <[EMAIL PROTECTED]> 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
