RTL language (right justification) support

[YaLTeR]

Also see discussion: #658

RTL languages like Arabic expect the visual layout to be mirrored horizontally somewhat. In case of niri, there isn't much layout to mirror: mainly we need right justification where windows instead of spawning and tending to the left, spawn and tend to the right side of the screen.

This is generally useful outside RTL languages, so maybe it could be a setting on its own, but RTL languages should turn it on by default.

Our navigation keys (e.g. focus-column-left, focus-column-right) are for the most part directional so they shouldn't need any special changes. Though, I'm not sure about focus-column-first and focus-column-last. What do text editors do when you hit Home and End on RTL? Does Home go to the start of the line (on the right)?

For determining whether the current language is RTL, here's what GTK does: https://gitlab.gnome.org/GNOME/gtk/-/blob/72718b719387d15a29bf4524bc721eec490b357e/gtk/gtkmain.c#L774

Finally, we'll also need to mirror the table in Important Hotkeys. (But maybe not until we actually have translations?) I can't think of anything else right away.

[bbb651]

I personally use English as my system language but my native tongue is RTL (Hebrew) so I can answer some of your questions.

This is generally useful outside RTL languages, so maybe it could be a setting on its own, but RTL languages should turn it on by default.

Like people said in #658, I don't think automatically detecting it is a good idea. If niri itself eventually supports localization it makes sense to follow that, but imo detecting it based on the system will confuse users not aware of the feature's existence.

What do text editors do when you hit Home and End on RTL? Does Home go to the start of the line (on the right)?

Yes - text editing will often includes mixed RTL and LTR, the way this works by default (i.e. html dir="auto") is each line can have it's own text direction based on the text directionality of the text that starts the line, and spans of text go the other way. In general, there's a distinction between logical directions and physical directions.

Our navigation keys (e.g. focus-column-left, focus-column-right) are for the most part directional so they shouldn't need any special changes.

I would imagine they would need to be flipped because the representation of columns should remain the same, but now e.g. right means decreasing the index instead of increasing it.
I think it'll be useful to have variants of commands that do follow logical direction rather than physical direction (*-next and *-previous), to allow for example to bind column focus to super + j/k or super + n/p (although ultimately not that big of a deal since they can be flipped manually in the config).

Edit: I think this will also work quite well with #757, keeping *-left and *-right actions the same as *-previous and *-next respectively but swapped if RTL layout is active makes the same binds works correctly across any combination of LTR/RTL and horizontal/vertical

[YaLTeR]

Like people said in #658, I don't think automatically detecting it is a good idea. If niri itself eventually supports localization it makes sense to follow that, but imo detecting it based on the system will confuse users not aware of the feature's existence.

Why not? If they have system language set to Hebrew for instance, GNOME and all GTK apps will be flipped automatically, and probably other apps too. Would make sense for niri to default to right-justified imo.

Yes - text editing will often includes mixed RTL and LTR, the way this works by default (i.e. html dir="auto") is each line can have it's own text direction based on the text directionality of the text that starts the line, and spans of text go the other way. In general, there's a distinction between logical directions and physical directions.

This makes sense. I also got feedback on Matrix that in VSCode Home will go to the logical start of an RTL line, so to the right. Which also makes sense.

I would imagine they would need to be flipped because the representation of columns should remain the same, but now e.g. right means decreasing the index instead of increasing it.

That is a good point. But it's from a code perspective, and I was asking about the UX perspective.

I think it'll be useful to have variants of commands that do follow logical direction rather than physical direction (*-next and *-previous), to allow for example to bind column focus to super + j/k or super + n/p (although ultimately not that big of a deal since they can be flipped manually in the config).

Hm, well that can be a separate feature request.