User directories integration - request for help

Alexander Larsson alexl at redhat.com
Mon Mar 19 11:01:11 UTC 2007


On Mon, 2007-03-19 at 11:42 +0100, Ralf Corsepius wrote:
> On Mon, 2007-03-19 at 11:13 +0100, Alexander Larsson wrote:
> > On Mon, 2007-03-19 at 10:51 +0100, Ralf Corsepius wrote:
> > 
> > > > It very much does. All applications using the gtk file selector will
> > > > have some default folders as file selector bookmars, and *all*
> > > > applications get translated filenames for common directories.
> > > 
> > > And all other applications, such as gui-less apps will be broken.
> > 
> > How are they broken? The only thing I can see that is possible to break
> > is if some application hardcodes ~/Desktop.
> Well, how is your local backup script to collect all music files from
> ~/Musique?

If you just want to backup the directory named "Musique" then it will
work fine just as before. If you want a special sort of backup script
that backs up the special MUSIC directory it would go:

test -f ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs && source  ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs
tar czvf /tmp/music.tar.gz ${XDG_MUSIC_DIR}

Thats a sort of weird backup script to have though. Backup scripts are
typically personalized for your homedir, and can hardcode whatever
structure you use.

> > > Related to this: Explain who all this is supposed without any
> > > login-manager (plain su -l without running any GUI)
> > 
> > If you don't log in through a gui then xdg-user-dirs-update won't be run
> > (unless you manually run it). 
> You've got it => Your i18n won't take effect. Non-GUI logins will have
> to cope with random side-effects of former logins.

What do you mean. Either you have previously ran it and there will be
i18n directories that we can correctly find, or there will be no special
directories. Things should work fine without any special directories
availible.

> Also did you consider simulaneously accessing dirs with different
> locales, e.g. network'ed (automounted) homes?

Yes, i did. You will have to pick one translation for your folder name.
This is the same as any other non-special folder names in your
homedirectory. You will have to select "don't ask me this again" once
you've decided which locale you want.

> > and shouldn't affect
> > anything (except you won't get the default dirs if you never run it).
> > Everything should keep working as it is right now.
>
> It will not - Nowadays one can write command-line scripts with hard
> coded/deterministic directory names to process the files in "Desktop" or
> "Pictures", "Music", "Documents", "Mail".
> 
> With your approach this won't be possible anymore.

Anyone can currently write a command line script that hardcodes
~/Documents, and they could in the past too. It will be broken now as it
was in the past. Users can do whatever they want with their
homedirectory and there is no guarantee that there will be a ~/Documents
directory (and there hasn't ever been one in Fedora).

Even for ~/Desktop which exist in some fedora users homedir it is not
right, as there is a home-is-desktop gconf key for gnome and a kde
config option for the desktop directory location.

But, this is not my main disagreement. My main disagreement is on the
idea that it is more important that you need two lines less code in some
script than that the users personal files should be in a language they
can understand. 

And translation of the filenames in the UI will *never* be complete.
There will always be 3rd party applications that don't translate the
names, and even in a translated desktop apps we need to show the english
name whenever we display a pathname.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a suave shark-wrestling astronaut with no name. She's a violent 
out-of-work pearl diver who hides her beauty behind a pair of thick-framed 
spectacles. They fight crime! 




More information about the fedora-devel-list mailing list