Merge lp:~widelands-dev/widelands/RTL-alignment-fix into lp:widelands

Proposed by Arty
Status: Merged
Merged at revision: 8920
Proposed branch: lp:~widelands-dev/widelands/RTL-alignment-fix
Merge into: lp:widelands
Diff against target: 15 lines (+3/-2)
1 file modified
src/ui_basic/textarea.cc (+3/-2)
To merge this branch: bzr merge lp:~widelands-dev/widelands/RTL-alignment-fix
Reviewer Review Type Date Requested Status
GunChleoc Approve
Review via email: mp+358596@code.launchpad.net
To post a comment you must log in.
Revision history for this message
bunnybot (widelandsofficial) wrote :

Continuous integration builds have changed state:

Travis build 4208. State: passed. Details: https://travis-ci.org/widelands/widelands/builds/453366074.
Appveyor build 4004. State: failed. Details: https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_RTL_alignment_fix-4004.

Revision history for this message
GunChleoc (gunchleoc) wrote :

I am having trouble with confirming the bug. Which screen did you get this in?

Revision history for this message
Arty (artydent) wrote :

I am not actually sure there is a place where this currently makes any difference visually.

Most text areas are used in automove mode and automatically change their position and size based on the text, so text alignment doesn't matter unless they are resized from the outside. In the cases where such resizing is done (e.g. window titles) the alignment is kCenter. So visially nothing has changed yet.

I made the fix mainly so that RTL would be displayed correctly when we use single-line textareas in non-center mode and with properly set layout. And we already do the same adjustment for multi-line textareas.

Where it theoretically could make a difference is the campaign select menu. That one uses some single-line textareas, but we don't have a layout defined there that would resize the text areas, so they stay collapsed to the text width and don't react to my fix yet. (And we might even put everything there in a multi-line textarea when we do a proper box layout.)

If you want to just quickly test it, set one of the menu title alignments to Left or Right. Without the fix, language doesn't make a diffence, with the fix alignment is swapped properly for Arabic.

Side note: Even the menus where we have defined a proper layout with multi-line textareas, some of them are not resized properly (like game/map name in the description area), so RTL is ignored.

I guess all this RTL stuff has very low priority anyway. Aside from a small amount of Arabic, we don't even seem to have translations.

Revision history for this message
GunChleoc (gunchleoc) wrote :

I still can't easily find an instance of triggering it and I don't want to search 128 constructor calls for the right one. The code looks reasonable, so let's have it.

@bunnybot merge

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/ui_basic/textarea.cc'
2--- src/ui_basic/textarea.cc 2018-07-08 13:53:45 +0000
3+++ src/ui_basic/textarea.cc 2018-11-10 18:48:51 +0000
4@@ -125,9 +125,10 @@
5 */
6 void Textarea::draw(RenderTarget& dst) {
7 if (!text_.empty()) {
8+ Align alignment = mirror_alignment(align_, text_);
9 Vector2i anchor(
10- (align_ == Align::kCenter) ? get_w() / 2 : (align_ == UI::Align::kRight) ? get_w() : 0, 0);
11- rendered_text_->draw(dst, anchor, align_);
12+ (alignment == Align::kCenter) ? get_w() / 2 : (alignment == UI::Align::kRight) ? get_w() : 0, 0);
13+ rendered_text_->draw(dst, anchor, alignment);
14 }
15 }
16

Subscribers

People subscribed via source and target branches

to status/vote changes: