Bug 211192 - Wrong arrows used for RTL languages
Summary: Wrong arrows used for RTL languages
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Unspecified
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords: rtl
Depends on:
Blocks:
 
Reported: 2009-10-20 12:52 UTC by Zayed Al-Saidi
Modified: 2024-09-14 17:06 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
wrong arrows used in RTL mode. (33.03 KB, image/jpeg)
2009-10-20 12:54 UTC, Zayed Al-Saidi
Details
GTK+ applection in RTL mode (97.94 KB, image/jpeg)
2009-11-11 18:57 UTC, Zayed Al-Saidi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zayed Al-Saidi 2009-10-20 12:52:44 UTC
Version:            (using KDE 4.3.1)
Installed from:    SuSE RPMs

Kget uses right arrows in RTL mode (see the attached screenshot). Kget should use left arrows instead.
Comment 1 Zayed Al-Saidi 2009-10-20 12:54:28 UTC
Created attachment 37683 [details]
wrong arrows used in RTL mode.


You can run kget in RTL mode by: kget -reverse
Comment 2 Matthias Fuchs 2009-11-11 02:33:29 UTC
Is there any KDE application that correctly uses these arrows, so that I could take a look at the way they solved it? As it should be a nice solution and not a hack.
Additionally is the play arrow in languages that are RTL also from RTL?
Comment 3 Zayed Al-Saidi 2009-11-11 07:46:25 UTC
(In reply to comment #2)
> Is there any KDE application that correctly uses these arrows, so that I could
> take a look at the way they solved it? As it should be a nice solution and not
> a hack.

Unfortunately, all the KDE programs that I see do not use these arrows correctly. It is common problem. Kaffeine, Dragon, Amarok, and kdenlive all of them suffer from this problem.

> Additionally is the play arrow in languages that are RTL also from RTL?

Yes, it is. It is simply in RTL languages, we start from right to left.
Comment 4 Matthias Fuchs 2009-11-11 14:17:42 UTC
And what is with the check mark [1] should it also be mirrored?

[1] http://mat69.files.wordpress.com/2009/11/signature.png next to Verified
Comment 5 Zayed Al-Saidi 2009-11-11 14:34:44 UTC
(In reply to comment #4)
> And what is with the check mark [1] should it also be mirrored?
> 
> [1] http://mat69.files.wordpress.com/2009/11/signature.png next to Verified

It does not need to be mirrored.
Comment 6 Anne-Marie Mahfouf 2009-11-11 14:48:50 UTC
Zayed, this is not a KGet bug as other KDE apps have it. This means it's a kdelibs bug.

We need a list for all icons/marks that should be reversed in any app, thanks.
Comment 7 Thiago Macieira 2009-11-11 15:01:03 UTC
The black-and-white arrow is a "Play" arrow, which is the direction a tape (cassette, VHS, etc.) turns. It should not change according to the language. I'm pretty sure tapes turn in the same direction in Arabic-speaking countries. Unless, of course, VCR makers decided to invert the arrows when creating stickers and their OSD displays.

The green arrow is an expand-collapse arrow. That one should either be inverted or use a different metaphor.
Comment 8 Zayed Al-Saidi 2009-11-11 18:55:58 UTC
(In reply to comment #7)
> The black-and-white arrow is a "Play" arrow, which is the direction a tape
> (cassette, VHS, etc.) turns. It should not change according to the language.
> I'm pretty sure tapes turn in the same direction in Arabic-speaking countries.
> Unless, of course, VCR makers decided to invert the arrows when creating
> stickers and their OSD displays.

I agree with you on the "Play" arrow should be in the the direction a tape turns but that for cassette,VHS, etc only and does not applicable for software. Right now, I feel all the KDE applications are weird regarding this issue. GNOME solves this issue. Please have a look on the attached screenshot below to see how GNOME's applications put "play" icon in RTL mode.

From Stock Items Documentation "Stock icons may have a RTL variant which gets used for right-to-left locales. " 
http://library.gnome.org/devel/gtk/unstable/gtk-Stock-Items.html
Comment 9 Zayed Al-Saidi 2009-11-11 18:57:17 UTC
Created attachment 38265 [details]
GTK+ applection in RTL mode
Comment 10 markuss 2009-11-12 10:49:36 UTC
(In reply to comment #7)
> The black-and-white arrow is a "Play" arrow, which is the direction a tape
> (cassette, VHS, etc.) turns. It should not change according to the language.

No matter how it's been in the 1980s, the position slider moves from right to left in Dragon Player when in RTL mode.
Comment 11 Zayed Al-Saidi 2009-11-12 11:18:59 UTC
(In reply to comment #6)
> Zayed, this is not a KGet bug as other KDE apps have it. This means it's a
> kdelibs bug.
> 
> We need a list for all icons/marks that should be reversed in any app, thanks.

From http://library.gnome.org/devel/gtk/unstable/gtk-Stock-Items.html

We need these:
goto-first
goto-last
go-back
go-forward
indent
unindent
jump-to
media-forward
media-next
media-play
media-previous
media-rewind
redo
revert-to-saved
undelete
undo
Comment 12 Christoph Feck 2009-11-12 22:16:15 UTC
I think there should be icons such as "media-play-rtl" etc. which are mirrored and used for RTL mode. We could also mirror them algorithmically, but that would also mirror any light direction in case light/shadow effects are applied to the icons. More work for Nuno :)
Comment 13 Yaron Shahrabani 2020-11-07 13:08:47 UTC
We are having the same discussion over at GNOME:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3313#note_953193
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/101

I don't think the arrows should point in the writing direction but there are several UI changes that should be done if we'll decide keeping the arrows like that.
Comment 14 Christoph Cullmann 2024-09-14 17:06:59 UTC
Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have resolved this bug.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann