>
> - 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).
>
> 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.
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?
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.
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) :)
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.
>
>
> 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 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.
I'll open a bug for an inline recent menu list.
Regards,
Djihed
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
