Re: GTK+ recent manager and RTL issues

[Behdad Esfahbod <behdad behdad org>]

On Tue, 2008-01-22 at 22:47 +0000, Djihed Afifi wrote:
> > 
> >   - 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 oppose this...It breaks the flow of the numbered list, that's the
> point of it after all (besides shortcuts). 

Shortcuts is a valid point, but other than that it's personal taste I
guess.

> > B) After your patch:
> > 
> >                         ELIF
> >   +-------------------------+
> >   |                    NEPO |
> >   +-------------------------+
> >   |            txt.OLLEH .1 |
> >   |            hello.txt .2 |
> >   |      hello world.txt .3 |
> >   |    ...it was a dream .4 |  <------------------- WRONG
> >   +-------------------------+
> > 
> 
> Good catch, I honestly haven't thought of this.
> 
> However, I'm concerned about how many files have trailing dots after
> all. I don't wanna try "find | grep "\.\.\.", but there is a low chance
> any file is going to turn up in my rather gigantic setup, or any file
> having neutral character ending at all. I can't think of any that are
> used.

I regularly edit text files without any extension.  Brackets are common
as well.  Anyway, I'm not a huge fan of exchanging one bug for another.

> It's a valid pitfall, but should we compromise the look of every RTL app
> because of the potential of this (very) rare file ending? 

No, who said we should compromise?

Also, if you want to do that, a cleaner fix would be to just turn
auto-dir off on menu items.  That's probably a right thing to do anyway.

"if (gtk_widget_get_default_direction())" should remain to an absolute
minimum.  What's the point of automatic RTL layout support in GTK+ if
every app has to do such things...


> I know, I know, half solutions and hacks are bad, but what happens with
> RTL bugs is that they sit in a "Paralysis by Analysis" mode for way too
> long. 

That's not true.  We don't have any major RTL issues in our platform.
That's where I really cared about.  For apps, bugs have been easily
fixed when someone cared enough to write a patch.

> The bug you linked below is there for literally 6 years. This is mainly
> due to lack of contributors with RTL knowledge and the time to fix these
> bugs. Those who do know them are already overwhelmed with stuff to do
> (like you) or not experienced enough (yet) to tackle them (like me) :)

No, lack of interest mostly.  I was theoretically interested in that
bug, because I want to have Pango be feature-complete, but I never had
concrete examples of where that support is useful except for the GAIM
message dialog.  Now I see more reason to fix it.

Make sure you check out these slides of mine btw:

  http://behdad.org/download/Presentations/bidi-layouts/

What I'm trying to say is, when you have a bug, come ask for the right
question first, only if it's not feasible think about workarounds.  Any
workaround is two days for your to come up with, but 5 years before
someone finds about it and fixes it properly.  Like someone said very
appropriately, any such fix leaves a scar in the project.

> And after all, these patches will be completly overriden with new code
> once a new inline widget is in place, or bug #70399 is fixed. So:
> temporary solution at least.

What if we never get there?  When we want to properly fix it, we have to
fix 10 places.  If it was a perfect fix, I'd had no problem with it
going in ten places.  Ten hacks is ten times more than one hack though.


> > 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.
> 
> 
> Just food for though: Another possibility is making the menu itself into
> two subwidgets, kind of how it is done now with :
> 
> Open     CTRL+N
> 
> With directional span's, one would still need to sycle between RTL and
> LTR possibilities: an LTR interface with an RTL filename has the same
> problem (in the opposite direction). To use your illustration with CAPS
> as RTL characters.
> 
> --------
> 1. file.txt
> MILAF.NAS .2 
> 
> So one needs to account for that. Unless the span auto adjusts according
> to parent widget direction, is that your plan? 

I don't have a concrete plan yet, but yes, whatever plan I come up with
will both both cases.

> > > 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.
> > 
> 
> You know, I do have the same mentality. I wouldn't like to hack and patch every app with dirty RTL code while it could be fixed at the source higher level.
> 
> I initially thought that me proposing a non standard widget to GTK+ is a near impossible and compilcated task . That's (obiously) false with Emmanuele's email.

Even if it was the case, would be better to copy the widget into libegg
if it's not already there, fix it, then just asks to resync their copy
with libegg.  The key point is, keep it to one place that needs to be
fixed later.

> I'll open a bug for an inline recent menu list.

Great.

> Regards,
> 
> 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