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