Re: RFC: Gnome-themes

[Ali Abdin <ALIABDIN aucegypt edu>]

Oh - I think this can be easily avoided - people are thinking complex 
solutions to very simple problems.

basically you need two files for a GNOME theme - one for the actual GNOME 
stuff, and one for the WM specific stuff - so we would have:

brushed-metal.tar.gz
brushed-metal-sawmill.tar.gz
brushed-metal-e.tar.gz
brushed-metal-wm.tar.gz
brushed-metal-bb.tar.gz 
etc...

That way each person can download the GNOME theme, and then OPTIONALLY 
download the window manager specific theme. Not that complicated - The 
potentially complicated part is to include some 'installation code' in 
the original GNOME theme on how it should handle the different WM 
specific files (i.e. installation paths).

Comments?

On Tue, 30 Nov 1999 u07ih@abdn.ac.uk wrote:

> Hi all.
> I've been thinking about the GNOME themes for ages now (at least since last
> night ;)and this is what I've come up with. Watch out, it's long.
> 
> Basic layout:
> A tarball which uncompresses into a themename.d directory, and contains an XML
> file giving all the theme information. Then subdirectories for cursors,
> gtk-theme, sounds, backgrounds and window manager themes.
> 
> ***This is not an attempt to start a flamewar***
> The major sticky point comes with window manager themes. A decision needs to be
> made, and I don't want to be the person who makes it. We obviously can't provide
> themes for every different window manager, as the size of the tarball could
> become huge - the average E theme seems to be around the 500K mark, so someone
> who uses say Windowmaker might get a bit annoyed at having to download a theme
> for E, and a theme for Sawmill, and so on. Another problem with trying to
> provide themes for every manager is that the theme creators are going to create
> the theme for their window manager, so some themes will only have an Etheme,
> some will only have a Windowmaker, and I think it would end up being a mess.
> 
> The other solutions are
> 1: Standardise on one GNOME window manager. Get it so that it is fully GNOME
> compliant and perfect, and include the themes for that.
> 2: Write our own "Window manager" theme and then either have the GNOME WM spec
> specify that a GNOME compliant WM has to be able to use our theme, or have some
> way of converting from our theme to different window managers.
> 3: Keep it the way we are at the moment (ie, non-WM-specific) and not include
> anything.
> 
> I'd give what I see as the advantages/disadvantages of each option but that
> really would be flamefest material
> 
> My personal choice would be choice 1.
> 
> I think what we should do is put a news item on GNotices with the arguments for
> and against the above options (and any others I've not thought of) and run a
> poll to see what people want.
> 
> Implementation:
> Again a couple of ways to do this.
> Either we can have a theme-capplet with different pages for each of the different
> theme sections, or we can have a new branch in the ctree for Themes.
> I think the second is the best way, because it seems to fit in with the way the
> control centre does it already.
> There would be a general theme capplet, that would handle setting and saving
> themes, and would also specify what parts of the theme were overridden by the
> users settings (eg, maybe the user wants to use a theme, but doesn't want the
> background to be changed)
> For the background and sound we can use the existing capplets (although sound
> doesn't work in the CVS libs, so it'll use the new sound capplet when thats
> available)
> The Gtk-theme capplet could be used as well, although maybe a theme colour
> selector could be added, the same way as the user font button was added.
> The cursors need a capplet, but as the cursor code isn't finished yet, this
> isn't a major concern for the moment.
> 
> I think thats everything, I've probably forgotten something, but please send
> your comments.
> 
> iain
> 
> 
> -- 
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
> 
>