Re: GNOME Theme Package Proposal

[Rodney Dawes <dobey novell com>]

On Mon, 2004-11-01 at 12:00 +0000, Thomas Wood wrote:
> On Sun, 2004-10-31 at 23:49 -0500, Rodney Dawes wrote: 
> > On Fri, 2004-10-22 at 22:18 +0100, Thomas Wood wrote:
> > > A New File Format
> > 
> > What new file format? This is mainly a directory layout proposal, and is
> > basically the same as the one I sent a couple years ago to
> > freedesktop.org that just got ignored. (yay!)
> > 
> > > `````````````````
> > > The directory structure should look something like this:
> > > 
> > > .
> > > |-- background/
> > > `-- splash/
> > 
> > There's no reason for these to be in sub-directories. The splash screen
> > really should be part of the icon theme anyway, I think.  At least, that
> > is if we don't just get rid of it entirely, since the main thing it does
> > is draw the icons on top of it, they should really match always.
> 
> I can understand your reason behind this suggestion, but then surely you
> should also include a background in your icon theme since icons are
> drawn on the desktop, and perhaps even a GTK theme since icons are drawn
> on top of the GTK theme. The fact that the icon theme is used to draw
> icons on a splash screen is implementation specific, so I don't think
> splash screens will ever be accepted into the icon theme specification.

No. People change wallpapers all the time. Splash screens pretty much
never change. The only reason the login splash is themeable at all, was
so that third-party vendors could change it without having to overwrite
existing images. Patching a string in an xml file is a lot simpler than
patching binary data. I wrote the code to make my job easier, not to
make all the �eet people happy by letting them theme their splash
screen. If we're going to allow splash screen theming, in a
user-acceptable manner, then we need to do it right. The current method
is not right. Putting splash screens into the icon theme, is.

> The reason for having sub-directories for these two items is firstly
> because it helps separation, and also that if the author wanted to
> include variants then they wouldn't have to be scattered around the root
> of the theme.

Themes are supposed to provide a consistent look and feel. Variants
would be other themes, not individual parts of a theme.

> > > |-- icon/
> > 
> > This should be "icons" I hope.
> 
> I used singular because it is the location of an (one) icon theme,
> rather than the location of the icons itself.

It is a location of one icon theme, which contains many icons. Surely
the icons would be in here as well, since they are what comprise the
theme. Besides, I've already got patches that add support for the
"icons" directory under ~/.themes/Theme/ that I need to clean up, and
submit as changes to the spec and implementation in gtk+/gnome, that I
am fairly confident will be accepted.

> > > 
> > > This should then be wrapped up in a gzipped tarball and given the 
> > > extension
> > > .gtp (Gnome-Theme-Package).
> > 
> > Whatever. I still think that we should just rely on the system packaging
> > systems to do this properly. Implementing dependencies for theme engines
> > and all that is not something that make a lot of sense for us to do,
> > since we already have things that handle dependencies.
> 
> I don't think theme engines should be included in theme packages, and as
> you say, they should be handled by distributions. Theme engines are
> software, and themes are images and text files. This is one of the
> reasons I created a separate section for theme engines on art.gnome.org.

How do you tell if a theme engine is installed, or if a particular theme
needs a particular engine, or set of engines, then? Themes are no less
software than theme engines. We should try to do "just works", rather
than "just works under certain phases of lunar rotations, when compiling
random tarballs off of art.gnome.org". Your proposal doesn't solve any
of the real issues that are bothering you. It just changes the filename
of the tarball to something you can more easily recognize. People are
still going to install themes and have them not work. That is the
biggest issue that needs to be solved. Everything else is trivial. The
main problem is needing to know which engines we need, and getting them
installed, not installing the themes themselves.

-- dobey