Created attachment 3804 a patch that fixes thunar-path-entry unescape and the locale names handling When a file name is being placed in the path bar entry, it's unescaped first. If you create a directory name like "foo%20bar" and enter it, the entry will contain "foo bar", and will behave as if a missing directory name is typed. OTOH, ftp file names containing spaces will be displayed with space instead of "%20" even without an explicit unescape. Another problem is that thunar_path_entry_set_current_file() receives real file names and places them into the entry without converting to utf-8, thus breaking any file names with non-utf-8 encoding - the locale characters are displayed with the replacement character, and of course, neither completion nor any action with them works. So I replaced g_uri_unescape_string() with g_filename_display_name(). Of course, glib manual warns that such conversion may be irreversible; but that only applies to names which can not be converted to utf-8, and such names will be always be broken when placed in the (utf-8) entry. Last, the entry completion functions compare the (utf-8) entry text against the real file names. That does does not work for locale names, and sometimes a g_assert() for a NULL string is displayed (probably a result of g_utf8_normalize(real_name), but I haven't tested that). Luckily enough, we have a utf-8 name corresponding to the real name - it's the display name, which fits with our new entry text. With ext2, which supports local and utf-8 encodings simultaneously, both are be displayed and completed correctly - but for locale names, the entry behaves as if a missing name is typed (the GTK+ Open/Save dialog works in exactly the same way). With G_BROKEN_FILENAMES or G_FILENAME_ENCODING set, the locale names work completely - but of course, any utf-8 names are displayed and completed as if they are 8-bit. Overall, IMHO, the patch improves the handling of locale names, and does not break the utf-8 names. It's really small and trivial.
First of all, I cannot reproduce the "foo%20bar" vs. "foo bar" issue. If using the location bar, "foo%20bar" and "foo bar" are displayed as "foo bar" and I can enter them by either typing "foo%20bar" or "foo bar". The rest of your comments may be valid, I haven't checked that yet. Just a general thought: we might be able to escape the conversion madness by using G_FILE_ATTRIBUTE_STANDARD_EDIT_NAME in places where it is appropriate. I'd prefer to get rid of any character-set-related code where possible.
Created attachment 3867 completion with unescaped name
Created attachment 3868 completion with escaped name
I'm sending screen shots (a small part of the screen of course) with filename completion using the unescaped and escaped names. Should be self-explaining.
Works fine here. Please reopen if this is still an issue with the latest Thunar release.
Created attachment 5059 New_Folder_No_Foo.png
Created attachment 5060 New_Folder_Bar
Created attachment 5061 New_Folder
Created attachment 5062 Locale_AB
I checked 1.6.3. Now let's create a good and easy to reproduce example... $ mkdir ~/'New%20Folder' $ touch ~/'New%20Folder/Foo' $ mkdir ~/'New Folder' $ touch ~/'New Folder/Bar' $ thunar ~/'New%20Folder' The path bar entry contains "New Folder". Let's try to complete it with /F for Foo... <New_Folder_No_Foo.png> nothing happens. How about /B then? <New_Folder_Bar.png> Wow, completes Bar - from the other directory. :) The only difference from 1.2.3 and 1.6.3 is that if "New%20Folder" exists, but "New Folder" does not, opening "New%20Folder" with 1.6.3 displays the red stop sign immediately: <New_Folder.png> whereas 1.2.3 shows it when you attempt completion. I hope my explanation was better this time. There can't be "works for me", since the same "New"<space>"Folder" text in the path bar simply can not refer correctly to two different directories. -- As of the locale names, there is no change either: <Locale_AB.png> I haven't checked the 1.6.3 source, but most likely it still puts the raw locale name in the UTF-8 path bar entry.
I have found this bug report after I have tried to fix the same issue as described in bug #8190. Can someone please compile current git and see if the issue is fixed, or if there are any problems with my fixes? http://git.xfce.org/xfce/thunar/commit/?id=a66687acff43b5b7196761514e15138706ad3385 http://git.xfce.org/xfce/thunar/commit/?id=bfa875b6a76f812d638f2e88ea27a2cf95e5be1f Related fix for the bookmarks in the shortcut pane: http://git.xfce.org/xfce/thunar/commit/?id=65adfa6552f2211e51caa0c23ecbbefc5ab96362
I'm closing this, as the current implementation seems fine and no one else has reported any problems.