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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list