Re: Directional Images
- From: fr33domlover <fr33domlover mailoo org>
- To: Dov Grobgeld <dov grobgeld gmail com>
- Cc: gtk-list <gtk-devel-list gnome org>
- Subject: Re: Directional Images
- Date: Thu, 17 Oct 2013 00:42:48 +0300
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
<fr33domlover 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]