After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 779099 - TextLayout: weird and probably wrong 'special case' in get_line_display()
TextLayout: weird and probably wrong 'special case' in get_line_display()
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
3.89.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-02-22 22:09 UTC by Daniel Boles
Modified: 2018-02-19 10:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
TextLayout: Clarify implementation of special case (1.43 KB, patch)
2017-03-01 20:29 UTC, Daniel Boles
accepted-commit_now Details | Review

Description Daniel Boles 2017-02-22 22:09:50 UTC
https://git.gnome.org/browse/gtk+/tree/gtk/gtktextlayout.c#n2282

If the line is invisible, this exits early after setting the layout
based on display->direction. But the latter is not set yet, so because
the LineDisplay is new0’d, the direction is always GTK_TEXT_DIR_NONE.
This hits the else case and means that we always create an LTR layout.

display->direction is only assigned to by the function set_para_values().

What is the real fix?

 (A) move this to under the final call to set_para_values(),
     so the right direction is available and right layout created?

 (B) delete the futile check and just always return the LTR layout,
     so the same behaviour as current is kept, without weird code?
Comment 1 Daniel Boles 2017-02-25 00:22:39 UTC
Setting the layout, and hence the read of the not-yet-set display->direction, was added in commit 86e4f7d1f305574a1d7e412efc56db8d02f23eb2
Comment 2 Matthias Clasen 2017-03-01 18:38:01 UTC
Moving it down would defeat the purpose - it is meant to be an early exist, avoiding all the extra work. The point being that with invisible lines, you can fit an infinite amount of text onto the screen...
Comment 3 Daniel Boles 2017-03-01 19:33:00 UTC
OK, so is it OK to always return an LTR layout, but patched to do it explicitly, rather than using code that does it 'accidentally'? or are there both (A) an important reason to return a contextual direction of layout for invisible lines and (B) a quicker/earlier way to determine what that direction should be?

put simply: what, if any, are the drawbacks of not returning an RTL layout for an RTL-but-invisible line? this is probably a simplistic question, but I know next to nothing about Pango and the GtkText* classes, and even less so about invisible lines therein
Comment 4 Matthias Clasen 2017-03-01 20:06:06 UTC
That change was written 12 years ago... I am hard pressed to remember anything about patches that are 2 years old. Given that the change has been in place for 12 years, I think it is safe to say that whatever the side-effect, it can't be terribly serious, since nobody has complained about it.
Comment 5 Daniel Boles 2017-03-01 20:29:13 UTC
Created attachment 346996 [details] [review]
TextLayout: Clarify implementation of special case

TextLayout: Clarify implementation of special case

This exists to exit early for invisible lines. It attempts to use the
LineDisplay’s direction to create a corresponding PangoLayout. However,
the dir is not yet set by this point, & the display was new0()d, so its
dir is always 0 == TEXT_DIR_NONE. Thus, we always create an LTR layout.

Whatever the original intent, this outcome seems to be OK, so let’s make
the code say what it means, rather than using a misleading conditional.
Comment 6 Matthias Clasen 2018-02-10 22:14:51 UTC
Review of attachment 346996 [details] [review]:

ok, lets do this
Comment 7 Daniel Boles 2018-02-19 10:01:03 UTC
Thanks for pushing to master. Shall we cherry-pick to 3.22 for the sake of keeping them similar?