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

[Craig Drummond]

> > ~/.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?

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

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

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

> > *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?

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

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

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

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

> 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

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

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post