Re: Installing themes from art.gnome.org via gnome-theme-manager

[Rodney Dawes <dobey free fr>]

I don't really think we should do it this way completely. Engines still
pose problems with this, since they need to be installed in system
locations. Most engines come with some amount of themes also, such as a
default gtkrc for it, and a metacity theme, and an index.theme to make
it be a metatheme. These are best managed by the system-wide package
manager, rather than the theme capplet. To make things work properly, we
also need dependency resolution, so that say pixmap themes can depend on
the pixbuf engine, and metacity themes can depend on metacity, etc...

On Tue, 2003-06-24 at 13:59, Thomas Wood wrote:
> In the efforts to make GNOME theming easier, especially in regards to
> those from art.gnome.org so as to make a.g.o the definitive source of
> GNOME themes, we have decided it would be to our advantage to
> incorporate better installation of themes so as to be able to integrate
> easy install of themes directly from a.g.o. Currently, installing themes
> from art.gnome.org is a two step (or more) process that requires first
> downloading the theme, then installing it, then switching to that theme
> and as a result of bugs in system tar, or in the theme manager itself,
> even this is not a hiccup free process. To overcome this, at least in
> part , a lot of modern programs (such as winamp, mozilla and others)
> allow the user to download, install and even switch to themes from a
> website in a single step process by a common extension which the program
> is associated with. I propose we make it easier for people to install
> themes by doing this to GNOME themes, by changing the usual .tar.gz
> extension to a special extension and having the theme manager associated
> with these files so that it can "open" and install them. I believe this
> would be the simplest solution. So for instance with a proposed new
> layout on a.g.o, the user would go to the Details->Controls section,
> click on "Install" of a theme they would like, and the theme-manager
> would auto-download the file, properly extract to the valid locations;
> and then prompt the user as to if they would like to apply the said
> theme now. 
> 
> 1. Extension
> This could be something like .theme or perhaps .gtheme, or anything else we all agree is appropriate.

Maybe we could do something like this and provide some metadata also, so
that we can verify that certain engines are installed and things.

> 2. Naming convention
> At art.gnome.org we currently prefix all themes with their theme type. For example, GDM themes are prefixed with "GDM-" and Metacity with "MCity-". We feel this brings some consistency to the file names and helps separate them. This could be included in some specification if necessary. So as to allow the theme manager to know by the file name where to extract said theme.

This shouldn't have anything to do with the nameing of the theme or the
filename of the tarball. We should work to get everything moved to
~/.themes/ aside from GDM themes of course, which must be installed in
the system, and therefore should be managed by the system packaging
manager. We could also provide information in the metadata for themes
which use older-style layouts such as ~/.icons/ or something else.

> 3. Internals
> This can either be left much as it is done in the theme tarballs now, or could be changed, although i don't see much need. Basically the structure is:
> 
> theme_name
>   |- index.theme
>   |- <gtk>
>   |- <gtk-2.0>
>   |- <metacity-1>
>   |- <scalable>
>   |- <48x48> ... and other icon theme related directories

I sent a proposal for something similar to this for metathemes a long
time ago go desktop-devel-list. I have some more changes to layout and
such that I want to propose on xdg-list soon also. It is basically a
proposal to move the icon themes into the $(datadir)/themes/ style
structure, and create standard names for icons, so that we can use the
same things across desktops and so that icon themes can theme more than
what they do currently. I've mentioned this on IRC a bit.

> 4 Implementation
> Essentially the theme manager would be associated with this type of file, and would install it in much the same as it does currently. What type of compression to use is an issue (gz or bz2) and how this would work on for instance a solaris machines would also have to be adressed (apparently solaris tar is different from gnu tar). And we should as stated, also have some sort of message dialog asking the user if they would like to apply now etc..

The type of compression shouldn't matter. We should support various
types of compression and provide a standard tool for creating the
tarballs. The difference between gnu/solaris/etc... tars doesn't really
matter much if we just use a standard library to do it, rather than just
running the "tar" command in the background.

-- dobey

> 
> Comments?
> 
> 
> ps. Please throw insults at ajgenius as to the lengthy-ness of some sentances in this proposal, as they where his idea.

PS: Line breaks are good. :)