recent-file-spec: possible design flow ?

[Oliver Braun]

Hi *,

we - the SUN team working on OpenOffice.org - noticed a possible design 
flow in the recent-file-spec (or at least in the Gnome 2.2 
implementation of it) when looking at the Ximian patches for OpenOffice.org:

it seems that Gnome 2.2 converts the full local file path to utf-8 
before encoding the result as file url. It uses the text encoding 
matching the current locale as "from" encoding. This is not reversable 
if the path contains bytes that are not valid characters in this 
encoding (multi encoding paths) !

The result will be that the application launched by the panel will not 
be able to open such a file when chosen by the user from the "Open 
Recent" menu. Unfortunatly we made the same mistake in OpenOffice.org 
1.x :(. The only way to handle multi encoding paths correctly seems to 
be to encode the byte sequence as returned by the file system layer.

The recent file spec says <QUOTE> All text in the file should be stored 
in the UTF-8 encoding.</QUOTE>, which IMHO can easily (mis- ?) 
understood as "convert file names to utf-8".

How does KDE expect file urls to be encoded ?
- Oliver