~/.themes [ Was Re: Icon Theme Spec and Cross-desktop Themeing]

[Rodney Dawes]

On Mon, 2003-08-04 at 10:59, Craig Drummond wrote:
> > As I understand it, XDG_DATA_HOME is just a hidden dir. Hidden
> > directories are not stupid at all. And ~/.themes is not adding
> 
> They are when you have:
> 
> ~/.gnome
> ~/.gnome_private (why6 isn't this ~/.gnome/private ?)
> ~/.kde
> ~/.qt
> ~/.gimp
> ~/.mozilla
> ~/.wine
> ~/.xmms
>  etc, etc...

They aren't stupid. They are legacy. And since there is a major lack
of integration on linux, and between open source projects, they need
to be there.

> And now you want also:
> 
> ~/.themes
> ~/.icons
> ~/.fonts
> ~/.thumbnails

I don't want these. I want ~/.themes for themes. I want to get rid of
~/.icons. These all already exist, so I'm not sure what you're whining
about.

> ...plus all the config files : ~/.gtkrc ~/.gtkrc, ~/.kderc, ~/.DCOP*, blah
> blah...

The .DCOP stuff is a few unix sockets for the DCOP server. ORBit puts
these in /tmp/ instead. I welcome you to create patches to move config
files to XDG_CONFIG_HOME, and to write a spec for storing configuration
data. Enjoy. I just think that moving all the data files to a sole
location in the immediate term is overburdening process that will end
up causing schedules to not be able to be met, which we can't do. GTK+
is already in soft feature freeze.

> Putting all config data, or whetever into ~/.config would make things much
> cleaner. I'm by no means the only person who wants tm omove all this rubbish
> into 1 place. It gets reall confusing when you do a ls -aF ~ -- theres way to
> many dirs. And surrounding the spec in an env var gives users the *choice* of
> moving these to a location of their preference!

This is what XDG_CONFIG_HOME is for. It is defaulted to ~/.config. But
configuration is separate from non-transient application data, such as
themes.

> > mechanisms. We could move them all to XDG_DATA_HOME, but that would
> > require a lot more work than initially moving the icon themes to the
> > same directory structure as themes initially. Perhaps later on, we can
> > move all themes to XDG_DATA_HOME, (assuming it is ~/.config, as stated
> 
> *surely* its better to do this now - before more and more apps/people assume
> ~/.themes is where they should be placed?

No. It's not actually. GNOME 2.4 will be out very soon. So GNOME won't
be doing this until the 2.6 cycle at least, anyway. GTK+ 2.4 is almost
at hard feature freeze, which means you probably don't have time to get
it done in this manner for GTK+ 2.4 and GNOME 2.6 in a reasonably good
code structure anyway. (I don't mean to be ignoring KDE here, but I have
no idea what their schedules or APIs are like in general. I don't know
them. I hack gtk+/gnome code.)

> > in another mail in your icon themes thread). Once all the themes are in
> > a central location, it's easier to to move them all, than to have a
> > large dispersal of different locations to deal with. I don't have the
> 
> Hence move them to $XDG_DATA_HOME/themes (or whatever the env var) is now.

Yes. Perhaps later. I never said "No. We can't do that.". I said we
should wait until the opportune time to do such things. Unifying the
icon themes between desktops and the directory layout with all types
of themes, seems much more urgent, so that we can fix some things before
we end up with a really really big mess of confusing things to deal
with, which will just making moving things around even more difficult
than they are already.

> > time to write a general theme spec right now, but we need one. I will
> > be making some patches to glib and gtk+ for the 2.4 release to make all
> > the theming stuff more abstract, so that people can easily support
> > themes in their applications or libraries or whatever. From what I
> > can tell from the web site, I need to do this by Sept. 1, which is the
> > hard feature freeze date for 2.4. Either way, I don't believe your
> > proposal is a solution to the overall problems of theming the desktop.
> 
> But why do you WANT to have a seperate dir? This is just madness... I can't
> beleive that writing a little bit of code to read an env var, and settnig a
> default if its not set, is that hard a task! If your going to move the
> location - as you say you are going to - then why not do it properly?

It's going to be a separate directory no matter if you put it at the
toplevel, or sweep it into some other directory structure. And the icon
themes directory layouts are already specified in the Icon Theme Spec.
So, I find it hard to understand why you are complaining about so many
things, when all that I am trying to address is fixing a few long-term
problems specific to Icon Themes, and one short-term problem (that could
end up being a long-term issue). It's not a question of difficulty of
writing code. It's a question of difficulty of requiring all existing
data to move there, or not work at all. I am doing it properly. Cleaning
up the existing problems, while providing backward compatibility, at
first, and then later moving everything around if need be. Your issue
seems to be more with configuration data, than themes. Perhaps you
should look at creating patches to applications and libraries to use
the XDG_CONFIG_* environment variables, rather than moving things that
are much less of a problem. And maybe change KDE's dcop server to write
the temporary unix sockets to ~/tmp/ instead of ~/.DCOP* or /tmp,
perhaps doing similar to ORBit or other similar things.

-- dobey