gtk: text direction in GtkEntry does not properly follow widget…

… direction with neutral contents when the widget is focused.

The code was introduced in commit f0d22047 to handle bidirectional text. It is mostly ok except in the focus case when text direction is suddenly bypassed. This provokes weird "jumping" text behavior as well as unexpected positionning despite explicit RTL direction.

---

Reproduction steps:

• Use a GTK application with a GtkEntry (my screencast below shows this with GtkSpinButton but the bug is on GtkEntry and therefore appears with both widgets), e.g. I use below the dimension field of the "new image" dialog of GIMP dev code. Note that it can easily be reproduced with a simple GTK program containing only a GtkEntry. I tested too.
• The entry must contain "neutral" directional text, for instance numbers.
• Have your software in RTL, either through the locale or by using the GTK Inspector > Visual > Text Direction to "Right-to-Left".
• Focus in and out of your entry.

Expected result: when you focus the entry, the neutral text should stay to the right as it is when the entry is focused out.

Actual result: the entry text suddenly jumps to the left (while it is to the right when focused-out, which is the proper direction). Text with a strong LTR direction should indeed be LTR, but here numbers are neutral so the widget direction (RTL in our case) should be used.

Peek_2022-04-09_22-35

You will notice that the text is in the proper direction when focused out. So it makes some really weird jumping right/left of the text which is disturbing. This is also why it does some weird selection of the text (because between my click and release, the text moved by itself, even though the pointer didn't, so it creates an unexpected selection).

Last but not least (for our use case), if you have custom widgets drawing additional things in the GtkEntry, it can break your expected behavior. We have this case in GIMP on a custom widget which is based on GtkSpinButton and drawing additional text on the other side of the entry (making sure it's big enough to have both the text and the numbers). Unfortunately since the numbers jump suddenly to the wrong side, both texts end up overlapping which basically breaks our widget (in RTL only, it's fine in LTR) as was reported to us with a screencast too: gimp#7944

The commit fixes the bug. Now the entry display works the same, focused or not.