recent-file-spec: possible design flow ?
Oliver.Braun at sun.com
Tue Jul 15 11:10:28 EEST 2003
I think we must differenciate here:
the first problem is that we can't present the file's name to the user
appropriatly if it has been created using a different encoding. This
problem could only be solved by adding multi-encoding support to the
file systems or to the file system layer (writing file names always in
utf-8), which is not very likely to happen. The same could be achieved
by installing only utf-8 locales on a system. Unfortunatly utf-8 locales
seem not be very popular in the CJK-countries.
The second problem is that even though it may not be possible for the
user to type the file name in his (different) locale, there is no reason
why he should not be able to _open_ it through either a (double-)click
in his file manager or a auto completion functionality in a file picker
Unfortunatly the sequence:
locale encoding file name -> unicode file name -> unicode file url
locale encoding file name -> file url (ascii) -> unicode file url
prevents the user from being able to do so :(.
Brenden T. wrote:
> Oliver's use case explains the issue pretty well. To me this sounds
> like a file system problem, not something the gui should try to
> solve. I don't see how any application can work if the encoding of
> file and path names is not precisely specified for a mounted disk.
> Heck, what happens on multi-user system? One guy starts up in C,
> another wants to use his native, non-english language, and they are
> both writing *differently encoded filename* strings to the same
> partition? *shudder*
> Does the Linux Standard Base define any type of filename string
> encoding? I'm too lazy to look it up...
> Seems to me like you should ask the file system people to put the
> encoding in the superblock. Then everybody uses the same encoding
> for a given mounted drive, and the app (or better, some system
> library) translates between what the file system encodes and what the
> user has requested be displayed. Then an admistrator could chose the
> encoding during installation, or a distro can choose a default (C for
> Red Hat boxes sold in the US, zh.BIG5 for a Chinese distro, etc., etc.).
> This may not work as well for floppy drives and CDROMs, but hey you
> have to start somewhere.
More information about the xdg