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

[Rodney Dawes]

On Tue, 2003-08-05 at 06:48, Craig Drummond wrote:
> > > ~/.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.
> 
> Just because they're legacy doesn't mean they aren't stupid. They are - 
> along time ago some sort of ~/.etc (or whatever) *should* have been decided
> upon. And isn't that part of this lists mandate?

This list wasn't around back then. And please stop arguing with me.
It's rather childish. "Yes they are." "No they aren't." "Yes they are."

> > 
> > > 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.
> 
> Wow - so we still have 3 extra hidden dirs, instead of putting them under 1
> top leve dir? Again, using an env var allows users to choose where to put
> them. Surely the code isn't that hard to write?

Did you actually read any of my mails? I never said the code was hard to
write. The card is usually not the hard part. The spec is hard to write.
And I don't have time to write two of them. Yes, we do need a general
theme spec. No, we don't have one. No, it's not an easy problem. You are
continually missing the point of anything I type. It is getting rather
tiresome to repeat myself.

> > 
> > > ...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
> 
> I've already been thinking about this. However, at the moment my spare time
> is rather limited at the mo - I'm getting married in 3 weeks, and still have
> a lot to arrange...

Then go arrange your marriage and stop arguing. :)

> > 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.
> 
> Well surely it'd be better to move a schedule by a couple of weeks so that
> things are done correctly? If you ship a GTK2.4 with the above listed dirs as
> standard, then they will become standard. Then if later you want to move
> things you get more breakages.

GTK+ isn't the only thing with a schedule. And no, if you do one thing
now and ten later, you won't necessarily get more breakage. In fact, I
am specifically avoiding that. It also seems rather daft to do it now,
when the distributions don't have any implementation of the spec, and
there exists no reference implementation, for something that is supposed
to cover a lot more than just the dot files in your home directory. The
issue here is not as big a problem as you make it out to be. People are
going to end up with a large directory listing no matter where you put
the files, if they intend on doing ls -aF. They'll just see ".desktop"
or whatever, and start looking in it's subdirectories. 

> > 
> > > 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.
> 
> So put it under a different env var? XDG_DATA_HOME??? I coulnd't care less
> about the name. I just want to clean up my $HOME

You misinterpreted everything I said. XDG_CONFIG_HOME is *for*
configuration. I just suggested using it. XDG_DATA_HOME is for
application data, such as themes. You are wanting to solve the
larger problem by solving part of a much smaller problem. It
just seems backward to me. Whether ~/.themes or XDG_DATA_HOME is
used for themes, you still end up with the same number of dot
directories to store them in. One. The real problem is all of the
config directories, some of which you are going to have more trouble
solving, than others... such as the realplayer or acrobat config.

> > > *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
> 
> But surely GNOME accesse this stuff via GTK, no?

Yes and no. GNOME 2.4 will use GTK+ 2.2 API. Therefore, it won't be
using the GTK+ 2.4 code to do theming. GNOME 2.4 will probably also
be released just before GTK+ 2.4. GTK+ 2.4 is already at a soft feature
freeze, which means no new features should be added anymore, but rather
the currently added new features should be cleaned up, fixed, or
whatever to be more stable.

> > 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
> 
> God hoiw hard is the code gonna be to write? An hours work?

So where is your patch? As I've said several times, it is not about the
difficulty of writing the code. There are many things I could do in an
hour that probably would not get into GTK+ 2.4, but would be
improvements. There is much more to software than code.

> > 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
> 
> Nope. Doing it now saves the pain later on.

You have not explained how. This is getting really tiring. Doing it now
doesn't necessarily save pain later on. It typically just creates more
pain now.

> > 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
> 
> Well if its under a env var then I can set up my desktop as (for example
> *only*):
> 
> $HOME/.desktop
> $HOME/.desktop/config         $XDG_CONFIG_HOME
> $HOME/.desktop/data            $XDG_DATA_HOME
> $HOME/.desktop/data/themes
> ...etc..

You are entirely missing any point of this discussion. And technically,
you can do most of this already with existing environment variables. At
least, in GNOME anyway.

> > 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
> 
> "properly" matter of opinion... messing up my $HOME seems more
> appropriate...

If matters of opinion are those backed by weeks of design and years of
experience, sure. Your $HOME is already messed up. In no way am I
proposing to create more dot directories in it. Your discussion has been
nominally unrelated to the original thread.

> > 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,
> 
> Yup I've already thought about doing this. For example, I've alread changed
> KDE's code to move $HOME/.gtkrc-kde to $KDEHOME/share/config/gtkrc

So how about a reference implementation for the Base Directory Spec,
then? Something we can get the distributions to use for their next
releases?

> > perhaps doing similar to ORBit or other similar things.
> > 
> > -- dobey
> 
> Craig.
> 
> (Sorry, this is *not* a personal attack on you - I'm just *very* fed up with
> the hundreds of .hidden stuff in $HOME. We have a chance to rectify this for
> the better - and to make backing up things much easier...)

A lot of people are fed up with dotfiles also. That doesn't mean you
have to reply to e-mails, apparently without reading them, and argue
with someone that nominally agrees with you. It's very frustrating to
get these anger-filled e-mails that continually whine about some small
issue, that is part of a much larger problem, when the smaller issue is
about to be fixed, and the larger part of the community agrees with the
existence of the larger issue and it's need to be fixed. Please stop
doing that. :) Thanks.

-- dobey