Kevin
March 28th, 2007, 06:14 AM
Ok, so we have gtk-window-decorator currently on compiz. Currently this does two things:
1. Provides a default theme that takes advantage of a composited environment. (Rounded corners, transparency, nice fonts, etc)
2. A wrapper that displays metacity themes on compiz. It has the ability to provide some features such as transparency, but that's about it.
Then we have emerald for beryl, now available for compiz. This provides a decorator that has the ability to display nice composited borders. The problem with beryl's emerald, is that in its quest to be DE independent, it needs its own theme-manager, its not integrated into DE specific tools, etc.
Now, there has been talk on th emailing list about using libdecoration to implement an svg decorator. But this could also have the same problems as emerald, needing its own theme managers, not integrated into gnome, etc. So I had an idea on which direction to take in implementing a new decorator that can be easily integrated into gnome, while still taking advantage of new features available in a composited environment.
The idea is actually quite simple.
First we would extend the current g-w-d to support themes that are svg based.
Themes for the extended g-w-d would be placed in the same method that metacity themes currently are. Themes right now are placed in /usr/share/themes or ~.themes. Within that, there is a folder for each theme, containing a gtkrc file, and a folder containing the metacity theme. There is also the index.theme file, which contains translations of the theme name, as well as the name of the gtk and metacity themes in the following two lines:
GtkTheme=Clearlooks
MetacityTheme=Clearlooks
I would propose adding a line to this file, like so
gwdTheme=NameofTheme
And then having a folder in the theme folder containing the files for the gwd theme. Since the metacity theme is in Metacity-1, I would think something like gwd-1, allowing for new versions of the decorator. This folder would contain the svg files, as well as somthing like an xml file detailing settings specific to the theme, such as button placement.
Next, the current gnome theme applet, would be extended to have a tab in the advanced options, similar to the current Metacity tab, to allow selecting the gwd theme independent of the overall theme. This tab would be written as a patch to the gnome themes applet, so that it could be submitted to gnome, and either integrated into gnome, or applied at the discretion of distros until its default.
If the index.theme file did not contain a gwdTheme line, the decorator would simply use the current method of using the metacity theme.
So as a quick example of this, I'll give an example. The current default gwd theme is clearly a composited version of the Suse gilouche metacity theme. So there would be a folder in /usr/share/themes called Gilouche, containing the gtk-2.0, metacity-1, and gwd-1 folders, as well as an index.theme file containing the lines:
GtkTheme=Gilouche
MetacityTheme=Gilouche
gwdTheme=Gilouche
This would make compiz use the composited version of the gilouche metacity theme if compiz is running, and the non-composited version if metacity was running.
This is the direction I think would make sense to enable composited window borders, and a similar approach could be taken with kde-window-decorator, conforming to whatever system is in kde. Any comments?
1. Provides a default theme that takes advantage of a composited environment. (Rounded corners, transparency, nice fonts, etc)
2. A wrapper that displays metacity themes on compiz. It has the ability to provide some features such as transparency, but that's about it.
Then we have emerald for beryl, now available for compiz. This provides a decorator that has the ability to display nice composited borders. The problem with beryl's emerald, is that in its quest to be DE independent, it needs its own theme-manager, its not integrated into DE specific tools, etc.
Now, there has been talk on th emailing list about using libdecoration to implement an svg decorator. But this could also have the same problems as emerald, needing its own theme managers, not integrated into gnome, etc. So I had an idea on which direction to take in implementing a new decorator that can be easily integrated into gnome, while still taking advantage of new features available in a composited environment.
The idea is actually quite simple.
First we would extend the current g-w-d to support themes that are svg based.
Themes for the extended g-w-d would be placed in the same method that metacity themes currently are. Themes right now are placed in /usr/share/themes or ~.themes. Within that, there is a folder for each theme, containing a gtkrc file, and a folder containing the metacity theme. There is also the index.theme file, which contains translations of the theme name, as well as the name of the gtk and metacity themes in the following two lines:
GtkTheme=Clearlooks
MetacityTheme=Clearlooks
I would propose adding a line to this file, like so
gwdTheme=NameofTheme
And then having a folder in the theme folder containing the files for the gwd theme. Since the metacity theme is in Metacity-1, I would think something like gwd-1, allowing for new versions of the decorator. This folder would contain the svg files, as well as somthing like an xml file detailing settings specific to the theme, such as button placement.
Next, the current gnome theme applet, would be extended to have a tab in the advanced options, similar to the current Metacity tab, to allow selecting the gwd theme independent of the overall theme. This tab would be written as a patch to the gnome themes applet, so that it could be submitted to gnome, and either integrated into gnome, or applied at the discretion of distros until its default.
If the index.theme file did not contain a gwdTheme line, the decorator would simply use the current method of using the metacity theme.
So as a quick example of this, I'll give an example. The current default gwd theme is clearly a composited version of the Suse gilouche metacity theme. So there would be a folder in /usr/share/themes called Gilouche, containing the gtk-2.0, metacity-1, and gwd-1 folders, as well as an index.theme file containing the lines:
GtkTheme=Gilouche
MetacityTheme=Gilouche
gwdTheme=Gilouche
This would make compiz use the composited version of the gilouche metacity theme if compiz is running, and the non-composited version if metacity was running.
This is the direction I think would make sense to enable composited window borders, and a similar approach could be taken with kde-window-decorator, conforming to whatever system is in kde. Any comments?