Re: GNOME Theme Package Proposal

[Thomas Wood <thos gnome org>]

On Mon, 2004-11-01 at 16:02 -0500, Rodney Dawes wrote:
> 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 über-leet 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.

I can see where you are coming from, I just don't think you will be able
to convince freedesktop.org to accept it into the icon theme
specification. So until it is part of the icon theme specification can
we not put it in here?

> 
> > 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.

But there are often colour variants of a theme. Should these not be
allowed into the same bundle?

> 
> > > > |-- 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.

That sounds great. If it the patch is accepted then we will not need an
icon/ directory at all. Perhaps if we just defined a more precise format
for index.theme, we wouldn't need any sub-directories at all. What are
people's thoughts on that?

> 
> > > > 
> > > > 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.

Yes this is a problem, but I don't think it's a problem that can be
solved easily, and it is a GTK theme packaging specific problem, not a
general theme package problem.

It could be addressed within the proposal, but there won't be any full
solution until there is a cross-platform and universal way of checking
what theme engines are installed. I think that is beyond the scope of
the proposal and would hold back the implementation. Also, if this
proposal was accepted as a freedesktop.org standard, it could not be
specific to any particular toolkit or implementation. For example, if a
KDE developer wanted to package a theme for KDE, it would not
necessarily contain a GTK theme at all.

What I would hope though, is that Andrew Johnson's very versatile
"Smooth" theme engine becomes the de-facto standard engine for GNOME,
and then this would be much less of an issue.


-Thomas