Re: GTK+ recent manager and RTL issues
- 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
GTK+ recent manager and RTL issues
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=102707action=view I started fixing this by patching the applications directly, forcing them to make the menu item to be RTL by using RLM. 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. 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? Related bugs (evince, eog, gedit, totem...) bug #509073 bug #509080 bug #509079 bug #509076 Djihed ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Arabic-Hindi digits vs. Arabic-western digits
Hi Waleed, A late reply, but better late than never. Ideally, this should be handled by the locale. If you are, say, from Saudia Arabia then your locale is ar_SA and arabic hindu numericals should be displayed. To make this possible, in translation (what we do), this should be done by substituting every %d (for integer), as well as other terms, with an %Id. However, the Arabic team does not do that at the moment because: 1) the old CVS system refused translations with %Id so we got carried away doing %d everywhere. 2) GNOME does not have a clear policy on this issue. The second ppoint is important because most developers don't mark some %d's for translation, so we can get a situation where an interface has mixed numericals. Which is a Bad Thing wrt consistency. We're hoping to shape up a proposal regarding this when we're ready. For now, if you absolutly need it, your solution is a very ugly hack: replace every arabic numerical in your font with a hindu one. Djihed في ن، 05-11-2007 عند 10:05 +0200 ، كتب Waleed Oransa: Hi All, I'm looking for an option to force Gnome or any GTK+ application to display Hindi digits instead of Arabic-Western digits. In other words, I need to change the shapes of digits in the display only while all digits will still stored in Arabic-western ASCII range. Is there any available option for that in Gnome if not does any one aware of similar option in KDE/QT? Thanks in advance. ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- Have a project you would like to be translated to Arabic? Let us know: http://wiki.arabeyes.org/Translation_requests Blog: http://djihed.com ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
GtkCalendar and day_selected event
Hi, I'm trying to use an instance of a GtkCalendar to allow the user to navigate through days. Other widgets respond to the selected day and present relevant information. However, using the day_selected event, the widget only accepts one click, after that, the day_selected event is apparently not fired on clicking other days. Ideally, I'd like the user to be able to navigate to as many days as they like. Is this achievable? Djihed ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
