GNOME Bugzilla – Bug 623241
item edit cursor misplaced
Last modified: 2010-07-13 15:58:42 UTC
new gnumeric start editing a cell in the edit line. enter unicode characters u05da followed by u05db. In the edit line the cursor is now placed correctly to the left of the last entered character u05db. In the item edit on the other hand it is to the right of character u05da.
Similarly, we get something wrong when clicking in an array expression.
Strange. I don't even the see characters U05da and U05db in the edit line until I add some ascii characters.
are you sure: <ctrl-shift-u> 0 5 d a <space> (you need to terminate input. This does not add a space character!) the character should appear on the very right.
Ah! I wasn't prepared to look there.
Seems that item-edit does not know about rtl mode.
I guess we should show the strong cursor (in pango language) since that appears to be shown in the editline (see pango_layout_get_cursor_pos).
I was wrong, the edit line shows both cursors: U+05da U+05db U+05dc 0 1 2 now click to the true right of the 2. The edit line shows the strog cursor in black and the weak cursor in grey.
the black and grey may be switched...? It seems that the strong cursor is grey here.
I'll have a look at that tomorrow.
Jean: thanks it appears that the edit line always shows just the strong cursor unless the user has clicked in a position where the strong cursor can't be but only the weak cursor. It then sows the weak cursor black and the strong cursor grey.
The strong cursor is actually black and the weak cursor grey. This is not very hard to implement, but we probably also should align the text in the item edit just like in the edit line. Also, selection is not always correctly highlighted. Runs have to be taken into account.
Created attachment 165183 [details] [review] patch This patch fixes the cursor issue and the selection issue, but the text is not always diplayed correctly and mouse selection is broken when the text is RTL.
Comment on attachment 165183 [details] [review] patch This is a huge improvement over the current situation. I would suggest you commit this already and then document the remaining problems in this bug report.
Created attachment 165229 [details] problem screen shot This screenshot shows one remaining problem. If we keep the interpretation of "left aligned" (being the physical left) we need to set the correct alignment for the layout. If we change the interpretation of "left aligned" to be "logical left , ie. towards the beginning of the text, then we need to move the layout to the correct side of the cell.
Comment on attachment 165183 [details] [review] patch Actually commited with a few changes because of selection colors issues.
Remaining issues in ItemEdit: - mouse interaction is broken when the text is RTL, - the item expands to the right instead of the left when the text is RTL and wider than the cell.
Mouse interaction is restored and the item now expands to the logic size, at least logic for me. The screenshot in comment #14 is related to cell rendering, and not to ItemEdit.
I'm unable to reproduce what I see in the screenshot. The default position is to the right of the cell. The only issue I see is that when I select left or right align, I obtain the reverse.
Created attachment 165683 [details] [review] Proposed patch for genral text alignment Please review. Looks like pango alignment logic is reversed when text is RTL. Weird...
Forgot to say that previous patch would need analog changes in print-cell.c
Review of attachment 165683 [details] [review]: With this patch I cannot replicate the problem sown in the screen shot any longer, but this patch appears to break the fix for bug #594193, ie. under horizontal fill we see again the unknown-glyph-symbol for the newline character ratehr than the bend arrow symbol.
I could fix that but I'm thinking that in filled mode, the text should be right align if rtl. Looks like that should be fixed in cell_calc_layout().
I agree that it probably should be right aligned. But I don't see the connection with us not breaking the fix that replaces the unknown glyph char with a known one, especially since your patch is not directly touching that code. So I gather that the code for that fix either is becoming inaccessible or its changes are being reverted by your patch. I did not look at the details for that.
Created attachment 165712 [details] [review] Updated patch This version does not reintroduce bug #594193.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. Fixed all alignment bugs I could find.