GNOME Bugzilla – Bug 310939
wrong filename encoding for application .desktop files results in broken menu entry
Last modified: 2006-04-15 23:39:12 UTC
Version details: 2.11.1.1-0ubuntu4 Distribution/Version: Ubuntu Breezy A wrong filename encoding (e.g. iso8859-15 on an UTF-8 system) for an application .desktop file results in a broken menu entry. The menu entry is visible, but clicking it doesn't work (because the file can't be found). When normally running an UTF-8 system start something like: $ LC_ALL=nl_BE LANG=nl_BE xterm And then in the new terminal create a .desktop file with accented or other non-ascii characters in the filename. (You can also use de_DE or en_US or something similar.) I'm not sure if such .desktop files should be included (e.g. how to represent such a filename in 'applications.menu'?).
I can't actually reproduce the problem you're talking about - if I create a foo€foo.desktop file with the filename in ISO-8859-15 encoding, it appears in the menu and launching it seems to work fine. I've fixed libgnome-menu to be aware of the issue of filename encodings, though: 2005-07-20 Mark McLoughlin <mark@skynet.ie> Fix things up so that we correctly handle different filename encodings. Fixes bug #310939 As far as the API goes, the rule is that the return value from gmenu_tree_entry_get_desktop_file_path() is in the filename encoding; everything else is UTF-8 * libmenu/gmenu-tree.c: (gmenu_tree_directory_make_path): Convert filename encoded basename to UTF-8 before appending to returned menu path. * libmenu/desktop-entries.c: (desktop_entry_new): don't load any .desktop files whose filenames aren't in a recognised encoding. * libmenu/entry-directories.[ch]: (entry_directory_new_full): convert UTF-8 path to filename encoding before loading; fallback to original path if UTF-8 conversion fails. (get_desktop_file_id_from_path): convert the filename encoded path to a UTF-8 desktop-file-id (entry_directory_foreach_recursive): don't pass the path and file_id to the callback; use the path as a file_id for .directory files. (entry_directory_get_flat_contents): convert filename encoded path of .directory file to UTF-8 before using as a desktop-file-id. (entry_directory_list_get_directory): convert UTF-8 path to filename encoding; fallback to original path if conversion fails. (get_all_func): we don't get passed the path anymore. (entry_directory_list_get_all_desktops): munge the code from entry_directory_list_add() in here since it was its only user.
What if your file system is UTF-8 but you end up with a file on disk with ISO-8859-15 encoding? This is what Jan and I were testing.
Okay, I'm re-opening this bug because I obviously never addressed the real issue of a "broken menu entry" So, I can't reproduce the issue. If I do: 1) Copy /usr/share/applications/gcalctool.desktop /tmp 2) G_FILENAME_ENCODING=ISO-8859-15 gedit /tmp/gcalctool.desktop 3) Change Name[en_GB]=Calculator to Name[en_GB]=Foo 4) Save as ~/.local/share/applications/foo€foo.desktop 5) Observe that € has been encoded in the filename as 0xa4 (iso8859-15) rather than 0xe282ac (utf-8) 6) "Foo" appears in the accessories menu, click it and it appears to work fine. Could you give me any more details on how to reproduce the "broken menu entry" problem?
This has been fixed for some time now...