After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 310939 - wrong filename encoding for application .desktop files results in broken menu entry
wrong filename encoding for application .desktop files results in broken menu...
Status: RESOLVED FIXED
Product: gnome-menus
Classification: Core
Component: libgnome-menu
2.11.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-menus dummy account
gnome-menus dummy account
Depends on:
Blocks:
 
 
Reported: 2005-07-19 22:31 UTC by Jan Claeys
Modified: 2006-04-15 23:39 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Jan Claeys 2005-07-19 22:31:30 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'?).
Comment 1 Mark McLoughlin 2005-07-20 15:33:01 UTC
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.
Comment 2 Travis Watkins 2005-07-20 16:37:55 UTC
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.
Comment 3 Mark McLoughlin 2005-07-25 10:49:59 UTC
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?
Comment 4 Jan Claeys 2006-04-15 23:39:12 UTC
This has been fixed for some time now...