Re: GNOME Theme Package Proposal

[Thomas Wood <thos gnome org>]

On Tue, 2004-10-26 at 10:21 +0200, Luca Ferretti wrote:
> Il giorno ven, 22-10-2004 alle 22:18 +0100, Thomas Wood ha scritto:
> 
> > The Problem
> > ===========
> > 
> > There is no mime-type or file format for packages that contain themes
> > and artwork that control the appearance of the GNOME desktop.
> > Historically, if an author has wanted to distribute a theme he has
> > made, then it is just a case of zipping up the directory of the theme.
> > However, these days authors often want to distribute several different
> > types of themes within the same package to create an overall
> > appearance across the whole desktop (window manager, icons,
> > background, e.t.c.). So far there is no standard format for theme 
> > packages...
> 
> Well, honestly I don't agree entirely. So let me expose my theme-blue-
> sky.
> 
> What is/should be themeable:
>         Widgets 	- managed via GTK+ themes
>         Icons		- managed via icon themes
>         Windows		- managed via metacity theme
>         Background	- optional
>         Splash		- optional
>         Font		- optional
> 
> Please note that those items should be __ORTHOGONAL__ (yeah, this is
> really important IMHO): this means that GTK+ themes should not provide
> gtk+ stock icons inside them. Note that now (GTK+ > 2.4) you can provide
> GTK+ stock icons inside an icon theme.

It is unfortunate that stock icons can be placed in GTK themes as well
as Icon themes. However this is an issue with backward compatibility
with previous versions of GTK so there is nothing much we can do other
than suggest that authors don't use this in their own themes.

> 
> Example: see Bluecurve. A really good and complete theme for widgets and
> for icons, but try to use its appearance for widgets and standard GNOME
> theme for icons. You'll have a really odd appearance, 'cause Bluecurve-
> gtk provides GTK+ stock icons.
> 
> So fist request for theme maker should be: respect orthogonality.
> 
> BTW one day icon themes will change the appearance of both GNOME and
> KDE, I hope, so it's important don't lock them in a GTK+/GNOME specific
> package.
> 
> BTW2 I hope that the orthogonality request will be applied to themes
> available on art.gnome.org and evangelized on gnome-look.org :-)

This is a good idea and perhaps something that art.gnome.org can
specialise in (that is, providing "correct" themes). I want to refocus
art.gnome.org at some point, and this is the kind of direction I want to
point it in. However, that discussion is for another thread.

> 
> Now, the second step is: how can I "pack" a theme that provide themes
> for widgets AND icons AND windows?
> 
> IMHO the answer is: use the theme index file (.theme file).
> 
> A theme index file includes the keys GtkTheme, IconTheme, MetacityTheme,
> ApplicationFont[1].

There would be no problem in adding Background and Splash-Screen support
too, as we are (re-)designing from scratch here. The system will be
totally new, so we can include anything we want!

> 
> Scenario 1:
> I'm a theme maker. I build up a new theme using, for example, Crux GTK+
> theme,  Nuvola icons and Glider metacity theme. I wrote the .theme file
> and publish it on art.gnome.org. People will download this file, will
> double click on it and the new (global) theme is "installed" and
> applied.
> 
> Scenario 2:
> I'm an user. I find a cool global theme on art.gnome.org, I download it,
> I double click on it and an alert will appear:
> 
>  ________________________________________
> |________________________________________|
> | Icons not available!                   |
> |                                        |
> | The theme you are installing needs     |
> | an icon option that is not available   |
> | on your computer. Do you want to       |
> | download it?                           |
> |                                        |
> |                 [ Cancel ] [ Download ]|
> |________________________________________|
> 
> The theme installer reads the keys, checks if options are available and
> eventually shows the alert.
> 
> The big trouble of this approach is that we need a standard location and
> a standard file name format for themes. Or a way to include the location
> in .theme file.
> 
> Or a new net protocol/service to search, fetch and make available
> themes. :-)

I'm not quite sure of the difference between your two scenarios are,
other than in the second one the theme package obviously hasn't provided
everything the theme needs. I don't think this is the way to go, as it
defeats having a single package format in the first place. All the
individual themes that make up the "Desktop Theme" should be included in
the theme package.

The font suggestion is the only aspect that I think should not have
files included in the theme package, since the ways of installing fonts
are more numerous and not standardised.

> 
> 
> 
> > A New File Format
> > `````````````````
> > The directory structure should look something like this:
> > 
> > .
> > |-- background/
> > |-- gtk/
> > |   `-- gtkrc
> > |-- gtk-2.0/
> > |   `-- gtkrc
> > |-- icon/
> > |   |-- index.theme
> > |   `-- scalable/
> > |-- index.theme
> > |-- metacity-1/
> > |   `-- metacity-theme-1.xml
> > `-- splash/
> > 
> > 
> > This should then be wrapped up in a gzipped tarball and given the 
> > extension
> > .gtp (Gnome-Theme-Package).
> 
> Dunno. I don't like it. Provide a new mime type just to pack theme
> options together is not a smart solution IMHO. .theme files are yet a
> description of a theme. Why create a new mime? Why don't extend .theme
> file format to retrieve missing options?
> 

The idea here is to use the existing index.theme files to describe a
"Desktop Theme" and and provide a known tarball directory structure for
the installer to work from. But also, the good thing about this idea is
there doesn't need to be any special tools to extract the package. The
user could just untar the package to ~/.themes and move the icons
directory to ~/.icons/<theme name> and the theme would be installed.

> 
> 
> [1] mmhhh there should be a background key too, but GNOME sysadmin guide
> don't report it. :-|