Re: GTK+ recent manager and RTL issues

[Behdad Esfahbod <behdad behdad org>]

On Sat, 2008-01-19 at 19:27 +0000, Djihed Afifi wrote:
> Hi,

Hi,

> Recent menus all over GTK+ applications suffer from misaligned text when
> they insert characters to make shortcuts, typically numbers (1, 2, 3...)
> each corresponding to a recent item entry.
> 
> Basically:
> 
> If the application is started in RTL, and the filename is in LTR
> characters, the recent menu name is rendered LTR and that is ugly for
> RTL languages.
> 
> The same thing happens when filename is RTL and app is LTR.
> 
> Here is a screenshot:
> http://bugzilla.gnome.org/attachment.cgi?id=102707&action=view

Sure, your "after" case as improvement.  But:

  - One can argue that a better fix would be for LTR filenames to render
LTR, but alinged to left margin.  The fix for that one would be very
easy too.

  - I'm pretty sure your fix doesn't work if the filename has trailing
dots.

Lemme illustrate.  CAPITAL letters are RTL:

A) Broken case before your patch:

                        ELIF
  +-------------------------+
  |                    NEPO |
  +-------------------------+
  |            txt.OLLEH .1 |
  |            2. hello.txt |
  |      3. hello world.txt |
  |    4. it was a dream... |
  +-------------------------+

B) After your patch:

                        ELIF
  +-------------------------+
  |                    NEPO |
  +-------------------------+
  |            txt.OLLEH .1 |
  |            hello.txt .2 |
  |      hello world.txt .3 |
  |    ...it was a dream .4 |  <------------------- WRONG
  +-------------------------+

C) Better fix:

                        ELIF
  +-------------------------+
  |                    NEPO |
  +-------------------------+
  |            txt.OLLEH .1 |
  | 2. hello.txt            |
  | 3. hello world.txt      |
  | 4. it was a dream...    |
  +-------------------------+

D) Another fix, not easy to implement right now:

                        ELIF
  +-------------------------+
  |                    NEPO |
  +-------------------------+
  |            txt.OLLEH .1 |
  |            hello.txt .2 |
  |      hello world.txt .3 |
  |    it was a dream... .4 |
  +-------------------------+


Case (D) is not easy to implement right now.  It needs ones to render
the number and the filename as separate fields.  I plan to add pango
attributes to make it easier, like in HTML for example.  This is the
tracker for that:

  http://bugzilla.gnome.org/show_bug.cgi?id=70399

Note that if you knew the direction of the subtext, you could get away
with sandwiching it between LRE/PDF or RLE/PDF, but there's no neutral
bid embedding character in Unicode.  So needs to be implemented in
markup.


> I started fixing this by patching the applications directly, forcing
> them to make the menu item to be RTL by using RLM.

Please CC me to all such bugs.  We really, really, should keep
RTL-specific code minimized and limited to as few modules as possible.
Apps definitely should not have to deal with this particular bug for
example.

I sure hope ebassi can be talked into adding the widget needed for those
apps to GTK+...

> Some developers rightfully suggested that handling this should probably
> belong to GTK+, by prepending RLM or LRM based on the direction of the
> application using gtk_widget_get_default_direction(). The shortcuts
> (numbers) are direction neutral so they will align correctly.

Two points here:

  - Adding RLM/LRM in 99 percent of the cases is not the correct fix!
Please discuss those with me first.

  - Instead of gtk_widget_get_default_direction() you probably should
use gtk_widget_get_direction() in most cases, using the widget at hand.
I didn't think of this before, but now that I do, it applies to most
patches that use gtk_widget_get_default_direction() I guess.


> My own opinion is that this belongs to the applications since
> gtkrecentmanager is not directly handling the presentation of the recent
> menu lists, even though it may look bad at first to fix it for all
> applications that have a recent menu list.
> 
> What do GTK+ developers think?

Well, if many apps want to use it (and I like the inline recent stuff
BTW.  I'd rarely look into recent files if they are not inline), I think
GTK+ should have it.

> Related bugs (evince, eog, gedit, totem...)
> bug #509073
> bug #509080 
> bug #509079
> bug #509076 
> 
> 
> Djihed
> 
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759