GNOME Bugzilla – Bug 710241
Fix the align in RTL and with GtkAlign
Last modified: 2018-04-14 23:58:01 UTC
It possible to set the align of a label. For example, set the „align” property to GTK_ALIGN_START will be align the lable to start. The direction of „start” changes according to two thing: according to the direction of the widget (LTR or RTL) - it is handled in GtkLabel, and also accordign to the content of the label - it isn't handled in GtkLabel. This mean, if I set the „aligon„ property to GTK_ALIGN_START: - In LTR the label will be align to left if the content of the label is LTR character, but it need to be align to right if the content of the label is RTL character. Now the label always aligns to left. - In RTL the label will be align to right if the content of the label is RTL character, but it need to be align to left if the content of the label is LTR character. Now the label always aligns to right. And vice versa with GTK_ALIGN_END. * Label with content of RTL character - this mean label is start with character of RTL language, e.g. character of Hebrew. I mean - need to align a also according to the content of the label. I see this problem in many of apps.
Created attachment 257922 [details] Geary - screenshot See the list of the conversations: The name 'From' is aligned to left, the title aligned to left and also the preview of the message is aligned to left.
Created attachment 257923 [details] Geary - screenshot in Hebrew See the list of conversations: The name 'From' is aligned to right, the title aligned to right and also the preview of the message is aligned to right.
I don't find the screenshots as very convincing for an auto-direction feature in GtkLabel. A) This is a pretty complex application - it makes sense to me that a mail client might need some RTL support code B) Each item in the conversation list seems to be made up of a number of labels - if the labels started aligning differently, it would look strange I think that Geary should be determining a text direction for each item in the conversation list and setting it explicitly. And in general, I think this is the problem - a GtkTextView is isolated from the surrounding layout inside a scrolled window, so auto-direction works pretty well - labels generally integrate into the surrounding layout. I think where a label is being used for extended display of non-predetermined text, some ability to make it auto-direction (or maybe auto-justification without auto-alignment?) would be useful, but I'm skeptical that there's any sort of "do the right thing" change we can make that is always going to be an improvement.
Geary is just example. I see this problem in many of apps. Very good example for this is the next log app of gnome - gnome-logs. In gnome-logs have a list of labels with a logs, and each label always align to right (in RTL ui), but the text of the logs is always in English. I think Geary can't deal with this problem, this must to do in GtkLabel. Maybe it can to be good idea to change the align right/left to 'the-direction-of-the-content' and 'the-pposite-direction-of-the-content'. I mean: When the developer try to align a label to right, with GTK_JUSTIFY_RIGHT or GTK_ALIGN_RIGHT, the developer want to align the label to the opposite direction of the content (usually is right, but if the content is Hebrew, this need to be left), and the default value is GTK_JUSTIFY_LEFT - the direction of the content. If we changed the behavior of GTK_JUSTIFY_LEFT (or GTK_ALIGN_) it can to be good solution (same to what I do in bug 710238).
If the expectation is that with gnome-logs, the logs are almost always LTR without regard to the UI language, then the text direction of the container of the logs should be set to LTR. To me, a developer is entitled to assume that a bunch right aligned labels will stay aligned - if I have a table: +---------------------------------------+ | Name: Joe Smith| | Date of birth: 5/5/1980| +---------------------------------------+ It doesn't make sense for it to turn into: +---------------------------------------+ | Name: HTIMS EOJ | | Date of birth: 5/5/1980| +---------------------------------------+ There may be additions needed to GtkLabel and/or Pango to make it easier to handle the sort of situations that you are describing - and I'd encourage you to try and fix up these applications and see what additions you need to make the application patches reasonable and not cumbersome. I'm not seeing an automatic solution in GtkLabel, however.
One suggestion I have made on irc is that we could maybe have an explicit text direction for 'content-derived'.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new