storage location for common user directories

[Alexander Larsson]

On Thu, 2006-03-09 at 03:26 -0700, Aaron J. Seigo wrote:
> On Thursday 09 March 2006 03:03, Alexander Larsson wrote:
> > To say that this was the conclusion is quite wrong. The conclusion was
> > that the translation of the filenames is a serious problem with various
> > possible solutions that all have their own issues and we were unable to
> > reach a consensus on what method was best.
> 
> i wonder if it would be possible to throw the translations into the .directory 
> file and keep a set of standard files to copy over in a system location? this 
> would mean that in addition to checking for .directory and various contents 
> therein, file browsers (managers, dialogs, etc) would have to check for a 
> localized version of the Name property.
> 
> it would be up to the folder API provided with the desktop env to do the right 
> thing when creating these folders ...
> 
> this would obviously fall apart on the command line, but would work in the 
> GUI. meh .. sounds like a massive hack =)

Gnome has stopped looking for .directory files for directories in all
but a few selected locations (like vfolders) due to the performance hit.

But even if we were to ignore that there are some problems with this
approach:
* Where do we put these files, and how does an app look up a specific
"type" of directory (say the "photos" dir). This needs some form of
configuration (or a well defined hardcoded set of paths).
* Who puts the file there, and who maintains the translations
I guess we could keep a shared copy in fd.o cvs and have each desktop
copy them to the right place on login
* How/When do you update it when there are new or changed translations.
If we always overwrite on login then you might overwrite users custom
names in the desktop file. If we don't, then the user will never get new
translations.

I used to think that the best way to handle this was to have the on-disk
filenames be in English, and translate things in the UI with a lookaside
buffer (basically a gettext file). If you have the locations in
well-known english directory name its very easy for apps to put things
in the right place, and we won't risk running into the (very common on
windows) situation where you have both an english programs folder and a
swedish programs folder because some apps didn't use the right API to
find the programs folder. It'll also always make pathnames stored in
e.g. config files and whatnot be the same, even if the translation
change.

This works well in Gnome, because we try our best to avoid presenting
raw paths in the UI, so we can almost always just display the translated
filename. However this would break for the terminal (imho not so bad)
and for apps in toolkits that aren't translating filenames (bad!).

These days I've changed my mind a bit, and I'm leaning towards a setup
where you'd use on-disk translated filenames. The way this would work is
that on first login we'd read some configuration of what folders and
translated folder names to use and create the folders and a
$home/.dirsrc file which would be in the form of a shell-script
key-value file, like:
DESKTOP_DIR=$HOME/Skrivbord
PICTURES_DIR=$HOME/Bilder

This is easy to parse for a desktop library, and its also easy to use in
a shell script (source ~/.dirsrc; cat $DESKTOP_DIR/some_file). 

There is a couple of tricky issues here. First of all we'd like to be
able to rename the folder, and even delete it and not get a new one on
the next login. I think this can be handled by special casing in the
file manager. If one of these folders is renamed we also change the
value in .dirsrc, and if we delete it we remove it from the file. In
both cases we also have to mark it in the .dirsrc file so that we don't
recreate it on login (if deleted), or re-rename it thinking we have a
new better translation.

Secondly we need to handle the case of updated (or new) translations
appearing. I think this can be handled by detecting the case where an
existing directory has a different name than what we would create it as,
but its not marked as user-edited. In this case we can throw up a dialog
asking the user whether he wants to use the new translation. The dialog
needs to warn about the problems that can be caused by changing the name
of the folder, as programs might have stored filenames with the old
folder name. We of course have to remember the answer in the .dirrc file
so that we don't ask this each time.

This setup allows the terminal, old apps and toolkits to display the
right names, it allows users to rename the well-known folders easily in
the UI, and it allows hard-core users to configure and disable folders.
Its moderately easy to use from a shell, and easily wrappable in a
desktop lib. 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an immortal crooked messiah who hides his scarred face behind a mask. 
She's a wealthy kleptomaniac vampire with an MBA from Harvard. They fight 
crime!