Recent files menu does not list files with non-Latin filenames (Windows)

[Alexander]

Recent files list do not saves files with non latin letter filenanes.
0.48(rus), WinXP SP3(rus)

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape 0.48.
Not reproduced on Ubuntu 10.04, Inkscape 0.48 and on Windows XP, Inkscape 0.47.

[su_v (suv-lp)]

Possibly related to
Bug #603442 “UTF characters in the meta-data title field not preserved”?
<https://bugs.launchpad.net/inkscape/+bug/603442>

[jazzynico (jazzynico)]

@~suv - yes, exactly! That's the report I was looking for, but I didn't use the correct keyword apparently...

[jazzynico (jazzynico)]

Still present on Windows XP, Inkscape trunk revision 11652.

[jazzynico (jazzynico)]

The bug doesn't happen when saving (the line correclty shows in the recently-used.xbel file), but when filtering the entries that populate the menu. If you comment the GtkRecentFilter in src/interface.cpp (lines 1020-1022), the UTF files show as expected (well, other files unrelated to Inkscape too, that's why there is a filter...).
Investigations in progress.

[jazzynico (jazzynico)]

The missing files are correctly encoded as UTF-8 in recently-used.xbel. Nothing wrong there.
What strikes me is that creating a GtkRecentFilter with no rule (with gtk_recent_filter_add_pattern (filter, "*");) hides the UTF files.

Note that other GTK applications such as Geany or Gimp are not affected (but I'm not sure how they handle the recent files and if they use GtkRecentFilter).

[jazzynico (jazzynico)]

Well, Geany uses it's own recent files code, and Gimp lists the GtkRecentManager's items and filters them manually...

[Patrick Storz (ede123)]

Status update:
- Inkscape 0.92.2 (764c4b8370, 2017-09-14) build with gtk2 2.24.31
  => issue still present
- Inkscape 0.92+devel (1da36c2be7, 2017-09-15) build with gtk3 3.22.19
  => issue seems fixed (at least German umlauts work)

I have a feeling it might have been fixed in gtk or does anybody recall any changes in Inkscape itself which could have fixed this issue?

[Patrick Storz (ede123)]

Issue tracked down further to the function
  gtk_recent_chooser_set_show_not_found()

It seems gtk is too stupid to find files with special characters and therefore excludes them from the list...
It still does not explain why it works without calling gtk_recent_chooser_add_filter (i.e. adding the "inkscape_only_filter".

[Patrick Storz (ede123)]

While I'm still not 100% sure why removing the filter works around the issue, I found the cause of it:

In [1] GTK+ is supposed to check whether the file in question exists and someone decided it would be a good idea to pass an UTF-8 encoded path to a function that expects the an ANSI string encoded in the systems codepage...

I reported the issue in gtk2 upstream and submitted a patch [2].
As for gtk3 I was right: It was already fixed "by accident" with an earlier patch [3] (which actually tried to address a different issue).

[1] https://github.com/GNOME/gtk/blob/35871edb318083b2d7e4758cbdaad6109eed60ca/gtk/gtkrecentmanager.c#L2236
[2] https://bugzilla.gnome.org/show_bug.cgi?id=787772
[3] https://bugzilla.gnome.org/show_bug.cgi?id=660730

[Patrick Storz (ede123)]

Patch merged and packaged in MSYS2, see
https://github.com/Alexpux/MINGW-packages/pull/2912

I think that's enough for now to mark this bug solved, let's hope the patch gets accepted upstream, too.