Re: Theme patriation

["Rui Tiago Cação Matos" <tiagomatos gmail com>]

Let's try again, there seems to be some common ground here. Even if small.

2008/10/27 Iain <iain gnome org>:
> Thats a pretty large jump from what you are proposing, which is
> essentially remove the -private from the library name
> and advertise the API.

Ok, there are 2 orthogonal issues:

1. Use the current Metacity theme format and to that end make that
library public. This seems like a bad idea for reasons already
enumerated. Only backwards compatibility with those themes might be
important.

2. Make GTK able to draw the window frame client side. At first sight,
this could be done in GtkWindow.

Kristian Hoegsberg has a nice analysis of this at
http://people.freedesktop.org/~krh/client-side-decorations.txt with
Pros and Cons.

> An application can already draw its own borders if it wants.
> The problem is that drawing it like metacity is difficult.
> Moving wholesale to saying that GtkWindow draws the borders by default
> is not the solution.
> Having a library that draws the themes is.
> That said, if an application wants to draw its own borders it either
> a) Doesn't want to look like the other apps on the desktop
> b) Wants to do something like federico's document saving thing or icanhasedit.
>
> In the case of a) they won't want to use any theme library we provide

Me, I don't like aliens on my desktop either so I personally don't
care about this category, though they would have their life made
easier by being able to do it subclassing GtkWindow and reusing
functionality from the default implementation there.

> and in the case of b)
> I fail to see any reason why we can't extend the WM spec to provide
> for these cases so that
> every app that needs it doesn't have to run through hoops to get at it.

This could be a way forward but would it ever be as flexible as doing
it client side? Artists are always coming up with shinier ideas :-)

> However, I believe that the Metacity theme format as it stands is a dead end
> a pain in the ass to create for the artist, write a parser for and draw.
> I would much rather move to defining themes via SVG and CSS than
> create a public API out of the current theme format.
> And this is something that I'm (slowly) working on.

Agreed. Moreover, the artist shouldn't have to create one theme for
the window frame and another for the window content.

Rui