recent-file-spec: possible design flow ?

[Oliver Braun]

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

Unfortunatly the sequence:

    locale encoding file name -> unicode file name -> unicode file url

instead of:

    locale encoding file name -> file url (ascii) -> unicode file url

prevents the user from being able to do so :(.

- Oliver


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