Created attachment 198297 [details] Document with English & Arabic for moving the caret around The caret in Libreoffice sometimes (but not always) presents with a direction indicator. Now, suppose I: 1. Set the paragraph direction to LTR 2. Type the text "abضcd" (i.e. type a, then b, then Arabic Dad ض, then c, then d) 3. Move back two characters, so that I am past the ض but before the c; the caret is now to the left of the ض, and shows a direction indicator. 4. Switch the keyboard layout back and forth between an LTR layout and an RTL layout (e.g. English and Arabic) Expected results: The caret direction indicator switches back and forth from pointing left to pointing right (or from pointing left to not appearing, with the caret being straight and symmetric). Actual results: The caret direction indicator remains pointing due left regardless of the keyboard layout change. The direction indicator should point in "the direction in which you're typing", which in our case is due left of the ض after step (3.), but changes back and forth in step (4.) . The attached document has text from step (2.), both in the body and in a textbox.
Does it matter what layout your keyboard has? I mean Latin numerals are always LTR and you probably type those with any keyboard. The caret responses to the current glyph in mixed paragraphs. That's perfectly fine IMO. => NAB
(In reply to Heiko Tietze from comment #1) What matter is where, relative to the caret, the sequence of characters would extend to. That _is_ what the caret direction indicator is supposed to indicate, right? Unless we As for Latin numerals - when you type them within an RTL context, the caret is at the leftmost edge of the text, and when you type another numeral - the new numerla is placed far away from the caret, and to its right, but - the number overall extends due left of the caret. PS - interesting to also look at what gedit does in the case you describe, which is split the caret! Although their typical caret has no direction indication. And we need to take another look at MSO behavior as well.
(In reply to Eyal Rozenberg from comment #2) > What matter is where, relative to the caret, the sequence of characters > would extend to. And that is exactly what we do. Adding Jonathan and Mike for opinions, my take is NAB.
Created attachment 198462 [details] Screencast ...illustrating the discussion.
Keyboard layout does not define directly directionality of a character entered using it. Additionally, I do not see the direction-indicator as "what *will* appear", but rather "what *already is* the direction in the caret position".
(In reply to Mike Kaganski from comment #5) > Keyboard layout does not define directly directionality of a character > entered using it. 1. Not define completely, but define typically. 2. I didn't base my argument on the keyboard layout defining the direction. Although... maybe I need to give some more though to what the caret direction should reflect. Maybe it actually is a good idea for it to reflect the keyboard layout typical-direction. > Additionally, I do not see the direction-indicator as > "what *will* appear", but rather "what *already is* the direction in the > caret position". The caret is not covering a character, so there isn't a direction in the caret position - unless you mean the paragraph direction. But - we already have an indicator for the paragraph direction. What's useful about the cursor direction detection is that it can tell you position-specific things; or perhaps, keyboard-layout-dependent things - stuff that you don't see by looking at the paragraph itself. (In reply to Heiko Tietze from comment #3) > (In reply to Eyal Rozenberg from comment #2) > > What matter is where, relative to the caret, the sequence of characters > > would extend to. > And that is exactly what we do. In some cases (as you've demonstrated with the screencast); and in some cases, we don't, as the reproduction instructions demonstrate. But this aside, I may need to rethink things a bit, as I've written Mike above.
(In reply to Eyal Rozenberg from comment #6) >> And that is exactly what we do. > In some cases... We don't for empty paragraphs or with content in just one direction. Adding the indicator means you don't know what character you will type - maybe happening when switching the keyboard layout. But such OS/DE-level function needs a proper indication there, and is to my knowledge done nicely. => NAB/WF (please resolve yourself)
(In reply to Heiko Tietze from comment #7) > We don't for empty paragraphs or with content in just one direction. 1. Well, that already doesn't respect the keyboard layout. And - it should. 2. We also don't do this in other cases - please don't ignore the reproduction instruction in the opening comment. > Adding > the indicator means you don't know what character you will type - maybe > happening when switching the keyboard layout. Whether I (= the user) know which character I'm going to type next, when I've just typed the last one, is a psychological question; I might be misunderstanding what you meant though. > But such OS/DE-level function needs a proper indication there, > and is to my knowledge done nicely. What we're doing now is done not-nicely-enough.
Rhetorical questions: what if you connect two keyboards to your system, or if the one keyboard is configurable and you type LTR and RTL content with the same hardware?
(In reply to Heiko Tietze from comment #9) > Rhetorical questions: what if you connect two keyboards to your system The keyboard itself doesn't have a layout defined. So, it doesn't actually matter. If you had a keyboard which allows direct insertion of strong-directionality characters of different directions at the same time, that would be a challenge. But it would also be a challenge to the DE. > or > if the one keyboard is configurable and you type LTR and RTL content with > the same hardware? Already happens now. With Hebrew (and probably Arabic, not sure) keyboard layout, pressing Shift + character key typically produces a capitalized version of the Latin letter corresponding to that key. This is fine (i.e. users accept the MSO similar caret behavior), because when such typing happens, the user knows that they are typing something that's out-of-the-ordinary in the current keyboard layout.
(In reply to Eyal Rozenberg from comment #6) > > Additionally, I do not see the direction-indicator as > > "what *will* appear", but rather "what *already is* the direction in the > > caret position". > > The caret is not covering a character, so there isn't a direction in the > caret position - unless you mean the paragraph direction There is. Basically, what is being actually shown now, is the direction that the *preceding* character has (and so, it's equal to the direction, which the caret travelled when passed the previous character). There is indeed an exception for the zeroth position. I do not know what would be good UX WRT this direction. I have no preference myself; if, instead of the current information, the "predominant direction of characters on the currently-active layout" would satisfy more users, I'm fine with that (and I don't know how e.g. Asian users do their input, and so I think that this needs some wider discussion outside of Western audience (which is unaffected), but including many maybe-affected communities).
Thinking more. Western community is affected, too. Even though I don't have any "RTL" layout, I still could benefit from the direction indicator - which would be totally impossible with your proposal. Namely, it was bug 163082, where a user entered a different-directionality character; the indicator showing *its* direction (and not of my input!) helped me to see the problem.
(In reply to Eyal Rozenberg from comment #0) > 1. Set the paragraph direction to LTR > 2. Type the text "abضcd" (i.e. type a, then b, then Arabic Dad ض, then c, > then d) > 3. Move back two characters, so that I am past the ض but before the c; the > caret is now to the left of the ض, and shows a direction indicator. > 4. Switch the keyboard layout back and forth between an LTR layout and an > RTL layout (e.g. English and Arabic) > > Expected results: > The caret direction indicator switches back and forth from pointing left to > pointing right (or from pointing left to not appearing, with the caret being > straight and symmetric). Suppose I put the cursor in the middle of an Arabic word and toggle between English and Arabic layouts. What directions should the caret point? Currently, the caret reflects the direction of the word at that position. By the above, though, I should expect the direction of the caret to change, since I've demonstrated intent to insert English text inside of the Arabic word. What if I'm in an English layout and use the arrow keys to advance through an Arabic document? I could insert an English character at any time. Should the direction follow the text, or the predicted most-likely direction of my input device? Should we worry about U+202E RIGHT-TO-LEFT OVERRIDE, etc.? The current direction indicator may not say exactly what users would want it to say, but it's predictable and very easy to explain. I see the vision, but it seems like it would be difficult to design this ER in a way that doesn't cause more head scratching. (In reply to Mike Kaganski from comment #11) > fine with that (and I don't know how e.g. Asian users do their input, and so > I think that this needs some wider discussion outside of Western audience > (which is unaffected), but including many maybe-affected communities). I'm not sure how much it matters for this discussion, but the lowest common denominator is using a US-layout keyboard with an IME framework that doesn't announce/associate languages with input methods. On these platforms, we may have no way of knowing a user is even able to type Han characters until it's already happened, and even then we still have no reliable way of knowing which language it's supposed to be. We should treat requests that require us to know the input language with care.
(In reply to Jonathan Clark from comment #13) > Suppose I put the cursor in the middle of an Arabic word and toggle between > English and Arabic layouts. What directions should the caret point? > > Currently, the caret reflects the direction of the word at that position. By > the above, though, I should expect the direction of the caret to change, > since I've demonstrated intent to insert English text inside of the Arabic > word. > > What if I'm in an English layout and use the arrow keys to advance through > an Arabic document? I could insert an English character at any time. Should > the direction follow the text, or the predicted most-likely direction of my > input device? The predicated most-likely direction of the input device. The text's direction is, typically, self-evident when looking at the area surrounding the cursor; you're reading the text, after all. But the direction of the character you're going to type is _not_ known, or predictable, when your eyes are on the area of the text where the cursor is; you would need to look for the visual indicator (if one exists) at the corner of the screen. > Should we worry about U+202E RIGHT-TO-LEFT OVERRIDE, etc.? If we decide to follow the keyboard layout, then - No. > The current direction indicator may not say exactly what users would want it > to say, but it's predictable and very easy to explain. I see the vision, but > it seems like it would be difficult to design this ER in a way that doesn't > cause more head scratching. 1. It is not easy to explain, nor predict, because it requires the understanding of which character is considered the one before the cursor. And that gets quite hairy exactly in those cases which this approach - i.e. caret direction follows previous char direction - is non-trivial. 2. That criterion is almost irrelevant as a comparison criterion. After all, the most easy to explain and predictable thing is not to have a caret direction at all. Perfect prediction, and nothing to explain. 3. If we choose caret direction by keyboard layout is quite predictable and easy to explain: RTL language keyboard layout - caret points left; LTR language keyboard layout - caret points right. Easy peasy. By the way, another example is text areas in Mozilla Thunderrbird. Just try it here on Bugzilla, when editing your comment! Add an RTL keyboard layout, and a switch key combination, and start typing. > I'm not sure how much it matters for this discussion, but the lowest common > denominator is using a US-layout keyboard with an IME framework that doesn't > announce/associate languages with input methods. On these platforms, we may > have no way of knowing a user is even able to type Han characters until it's > already happened, and even then we still have no reliable way of knowing > which language it's supposed to be. In that case - a no-direction caret is what I'd expect.
(In reply to Mike Kaganski from comment #12) Well, first, there's the question of frequency of that scenario. Looking at the caret to figure out what a typing would achieve is not just frequent, it happens whenever your work on the document involves typing in languages with different directions - for every single such document, in every LO module, always. Identifying a character's directionality is a niche situation and relatively rare even in that niche (i.e. you don't need to identify that again and again). Moreover - have we ever taken a decision that this is what the caret direction indicator should represent? I mean, all the examples I can find so far, to the extent that they even have show caret direction indicators, use it to reflect the implicit keyboard layout direction. There would need to be a strong argument in favor of having a conflicting semantic for it. That said - it would be nice to be able to make a selection and get a visual indication of the directionality of the selected characters: RTL, LTR, mixed or neutral. But the caret is not what I would use for that.
Created attachment 198514 [details] Screencast: Caret in "Hello world" and "שלום עולם" paragraphs (both LTR) (In reply to Mike Kaganski from comment #11) > Basically, what is being actually shown now, is the direction that > the *preceding* character has (and so, it's equal to the direction, which > the caret travelled when passed the previous character). Maybe that's true in some cases, but certainly not always. Attaching a screencast...