Bug 172630 - [BiDi/Unicode] Cursor direction dependent upon last letter typed, not selected keyboard layout
Summary: [BiDi/Unicode] Cursor direction dependent upon last letter typed, not selecte...
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: kwrite (show other bugs)
Version: unspecified
Platform: Ubuntu Unspecified
: NOR minor
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-12 02:33 UTC by Dotan Cohen
Modified: 2023-04-04 19:34 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2008-10-12 02:33:30 UTC
Version:            (using KDE 4.1.2)
Installed from:    Ubuntu Packages

In Kate on KDE 4.1.2 (I have not had the oppourtunity to test other KDE 4 applications) the cursor direction indicates the direction (RTL / LTR) of the last letter typed, not the selected keyboard layout. For instance, if the user is in English layout and types "Hello" then switches to Hebrew layout, the cursor still shows as LTR direction (lip pointing to the right).
Comment 1 Dotan Cohen 2009-03-17 15:09:05 UTC
Confirmed in KDE 4.2
Comment 2 Dominik Haumann 2011-07-20 07:00:42 UTC
Is that still the case?
Comment 3 Dotan Cohen 2011-07-20 13:18:24 UTC
Yes, this is still the case on Kate Version 3.6.5 Using KDE Development Platform 4.6.5
Comment 4 Christoph Cullmann 2012-11-02 22:46:25 UTC
Seems we have serious problems with this, anybody could help out with some patch?

*** This bug has been marked as a duplicate of bug 165397 ***
Comment 5 Dotan Cohen 2012-11-03 08:50:43 UTC
Thank you Christoph. This is not a dupe of bug 165397. That bug concerns the direction that the cursor moves when pressing the arrow buttons. This bug concerns the appearance of the cursor.
Comment 6 Dotan Cohen 2012-11-03 15:24:32 UTC
I just confirmed that this bug is still present in KDE 4.9. Considering some of the other RTL issues this is pretty minor so I'm marking it as such.
Comment 7 Diego Iastrubni 2012-11-09 21:21:50 UTC
Dotan, 

I would like close this bug as wont-fix. I think that the feature will be implemented not depending on the KB layout, but on the paragraph content. I am not convinced that what you describe is correct (show me another application/OS that does this to test and see by myself).

See also (I am working on that bug right now):
https://bugs.kde.org/show_bug.cgi?id=165397
Comment 8 Dotan Cohen 2012-11-10 18:20:51 UTC
Diego: most applications (such as Firefox) don't show a different cursor for each language direction. In fact, I would have no problem with that being the case, if Kate were to show the same cursor for each language. But the current implementation in which the wrong cursor is shown is in fact a problem.

I do know that the Mac applications does show a different cursor for RTL and LTR, but I'm not sure about Windows applications and other MS software. LibreOffice does show the different cursors per language directionality, but it is even buggier than Kate's!

I suggest to "won't fix" this bug by just showing the same cursor in Kate. Even other KDE applications, such as Konqueror's address bar, show the same cursor per language directionality.
Comment 9 Dominik Haumann 2013-08-14 10:00:34 UTC
Diego, any further comments on this?
Comment 10 Zayed Al-Saidi 2013-08-16 18:10:07 UTC
For my understanding, the kate should capture the event of changing the keyboard layout then change the cursor maintaining the focus during this process.  While this is a good future, I do not see a great benefit from it.  The only application (to my knowledge) has this future is Firefox but it takes around 3 sec to change the cursor!!

The current implementation of kate (I'm using KDE 4.10.4) will change the cursor to correct one after entering a new letter. This behavior is same as other Qt applications and libreoffice.
Comment 11 Christoph Cullmann 2014-09-23 19:22:45 UTC
Is that now ok the way it is or not? ;)
Comment 12 Dotan Cohen 2014-09-29 09:09:06 UTC
@Christoph: No, the situation today is exactly as it was in the OP.
Comment 13 Justin Zobel 2020-10-25 07:21:52 UTC
Dotan can you please confirm if this is still an issue in Kate from KDE5.
Comment 14 Bug Janitor Service 2020-11-09 04:33:37 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 15 Dotan Cohen 2020-11-09 12:21:47 UTC
@Justin Zobel: No, the situation today is exactly as it was in the OP.
Comment 16 Dotan Cohen 2020-11-09 12:22:26 UTC
@Justin Zobel: No, the situation today is exactly as it was in the OP.
Comment 17 Bug Janitor Service 2023-03-29 11:49:17 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/532
Comment 18 Christoph Cullmann 2023-03-29 19:42:14 UTC
Git commit 5934689df192aa681c6d7856bd6eaed9f22790a5 by Christoph Cullmann, on behalf of Waqar Ahmed.
Committed on 29/03/2023 at 18:10.
Pushed by cullmann into branch 'master'.

Draw caret ourselves

Drawing caret ourselves helps solve a few issues:

1. With custom line height, the caret is no longer smaller than line
2. Cursor direction depends on the block content, not keyboard layout
(bug 172630). Our own cursor will not draw the direction marker and
thus will avoid this issue
3. Make cursor insertion point a few pixels larger vertically (bug 452853).
You can just increase the line height and the caret will be bigger :)
Technically, this is not exactly what is requested, but it works. Making
Cursor visually larger than the line is _possible_ but it means that now
we need to _always_ dirty 3 lines for repaint: current line, line above,
line below which is a lot of uneeded work for such a small thing. So this
will do.

It is also more efficient than the Qt implementation as the work done in
here is a lot less.
Related: bug 452853

M  +24   -1    src/render/katerenderer.cpp

https://invent.kde.org/frameworks/ktexteditor/commit/5934689df192aa681c6d7856bd6eaed9f22790a5
Comment 19 Dotan Cohen 2023-03-29 22:46:41 UTC
(In reply to Christoph Cullmann from comment #18)
> Git commit 5934689df192aa681c6d7856bd6eaed9f22790a5 by Christoph Cullmann,
> on behalf of Waqar Ahmed.

Thank you, I look forward to testing this.
Comment 20 Waqar Ahmed 2023-04-04 19:34:04 UTC
Git commit 9a07647ee120da5b046cc71186590decebc8ded9 by Waqar Ahmed.
Committed on 04/04/2023 at 18:59.
Pushed by cullmann into branch 'kf5'.

Draw caret ourselves

Drawing caret ourselves helps solve a few issues:

1. With custom line height, the caret is no longer smaller than line
2. Cursor direction depends on the block content, not keyboard layout
(bug 172630). Our own cursor will not draw the direction marker and
thus will avoid this issue
3. Make cursor insertion point a few pixels larger vertically (bug 452853).
You can just increase the line height and the caret will be bigger :)
Technically, this is not exactly what is requested, but it works. Making
Cursor visually larger than the line is _possible_ but it means that now
we need to _always_ dirty 3 lines for repaint: current line, line above,
line below which is a lot of uneeded work for such a small thing. So this
will do.

It is also more efficient than the Qt implementation as the work done in
here is a lot less.
Related: bug 452853

M  +24   -1    src/render/katerenderer.cpp

https://invent.kde.org/frameworks/ktexteditor/commit/9a07647ee120da5b046cc71186590decebc8ded9