Created attachment 102714 [details] [review]
Fix.

By adding an RLM character.

Wouldn't that break filenames appearing in arabic? It seems to me that it would. Moving to GTK+ as there should be a function to handle that in the recent files framework.

Created attachment 102722 [details]
It's not a problem with various RTL files names

Bastien, au contraire, the behaviour was always right when file names were RTL, and introducing an RLM does not affect this.

Also, I think this is a totem bug. It constructs shortcuts by prepending numbers, so I don't know what in GTK+ could fix this.

Bastien, how would this be solved in GTK+? 

If it can be, then it would be wonderful to do that once and for all.

(In reply to comment #4)
> Bastien, how would this be solved in GTK+? 

it can apparently be solved by:
- totem (and other applications) switching to GtkRecentChooserMenu and not reimplementing a widget;
- somebody writing an inline widget and including it into gtk+.

if applications developers decide to implement a new widget there's not much gtk+ can do about it; language directionality support should be added to every widget - it's not something that gtk+ magically gets by the mere fact of being gtk+.

for the inlined widget, and the related usability discussion, see bug 349541.

Comment on attachment 102714 [details] [review]
Fix.

reflecting ebassis comment in patch status

(In reply to comment #5)
> (In reply to comment #4)
> > Bastien, how would this be solved in GTK+? 
> 
> it can apparently be solved by:
> - totem (and other applications) switching to GtkRecentChooserMenu and not
> reimplementing a widget;

That wouldn't fix totem, since gtkrecentchoosermenu gets it wrong too. Just create a file named "X.txt" replacing X with א (U+05D0), open it in gedit, then try testrecentchoosermenu.

We do not have a recents in the menu anymore