You're right, drop shadows don't work well when flipped. But I have three suggestions:
1. When widgets do enable perfect clean flipping, use it 2. When an app has two directional matching widgets, e.g. left and right arrows, simply switch between then instead of fliping. This will probably require an "matching image" object property 3. Add guidance to the Gnome devel docs, which explains how to write just few extra simple lines which makes your app more RTL-ready, so that we won't need to "hunt" and fix the same bugs again and again in each new app/design/implementation/version On ד', 2013-10-16 at 23:25 +0200, Dov Grobgeld wrote: > No, I don't think it is universally reasonable. Because in general an > icon may have a style that is broken when the image is flipped. > Imagine e.g. if the buttons in some style contains arrows that were > drawn with an elliptical pen slanted at 45 degrees to the right. In > such a case the left and the right arrow are not a mirror image of one > another. Another example is if the style contains a drawing with > dropshadow to the right. Horizontally flipping the image would put the > drop shadow to the left, which would be inconsistent with the rest of > the theme. You may claim that if this was done throughout the > application then it wouldn't make any difference, but if e.g. have an > embedded label with "Latin name: " and an LTR widget then it would be > inconsistant within the application. Even between applications that > have either LTR or RTL directionality on the desktop would look > inconsistent. > > > Thus, imo there is no automatic solution, but you need to create > dedicated RTL images to make things look good in a RTL environment. > > Regards, > Dov > > > > > > On Wed, Oct 16, 2013 at 11:58 PM, fr33domlover > <fr33domlo...@mailoo.org> wrote: > Hello Gtk+ developers, > > My native language is an RTL language. I've been examining > several RTL > problems in GNOME software recently, and I noticed some > recurring > patterns. > > Some of them are related to text alignment and fonts, which I > won't talk > about this time because I haven't found a universal solutio. > But I think > I did find a solution for images. > > It is very common for images where the direction matters, such > as > prev/next arrows, to be in the wrong direction when apps run > in RTL > locales. So far, a volunteer has been fixing these problems by > hand by > sending patches to all GNOME software containing the problem. > For > example, the prev/next arrows in Epiphany and in Evolution's > notification-bar bubble. > > Here are some related bugs: > > https://git.gnome.org/browse/rhythmbox/commit/?id=eb4641a127828a0fa567eb19c26c66ff7f3b2f52 > > https://git.gnome.org/browse/totem/commit/?h=gnome-3-10&id=9055f411d2332c43c725ccbb88f5f7c240885e91 > > https://git.gnome.org/browse/totem/commit/?h=gnome-3-10&id=3ff23cf41e0192860ee2ad5c70c99c3c4d024196 > > > Instead of doing it by hand, or trying to teach developers how > to make > their apps direction-aware, I found a universal solution which > requires > a bit of work once, and will work after that without any > developer > intervention. > > The idea is: Directional Images. > > Example: An arrow is a directional image. The direction of the > arrow > matters. When an arrow icon is rendered in RTL locales, it > should be > rendered horizontally flipped, so right becomes left and left > becomes > right. > > A folder image is a non-directional image. Changing its > direction > doesn't make any sense or different in any direction or > locale. The same > is true for people's faces, an image of the Earth, a map of a > city, etc. > > The solution I suggest is to add a "directional" boolean > property to > GTK's image class used for icons. The property will be stored > as image > metadata, and set by the designer of the image. After that, > the code > which renders the menu/toolbar icons will just need to check > if the > image is directional and the locale is RTL. If both are true, > draw the > image horizontally flipped. Otherwise, draw as usual. > > I believe it shouldn't take extra resources, because the > drawing loop > will simply need to fill pixels from the other side. No extra > processing > is required (unless computing "size - x" in each loop > iteration is too > much slower than just "x", which I doubt"). > > Is it possible? Does it sound a reasonable approach? > > > > fr33domlover > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
