172630 2008-10-12 02:33:30 +0000 [BiDi/Unicode] Cursor direction dependent upon last letter typed, not selected keyboard layout 2023-04-04 19:34:04 +0000 1 1 2 Applications kate kwrite unspecified Ubuntu Unspecified RESOLVED FIXED NOR minor --- 1 kde-2011.08 kwrite-bugs-null christoph elcuco justin.zobel kde-2011.08 zayed.alsaidi https://invent.kde.org/frameworks/ktexteditor/commit/9a07647ee120da5b046cc71186590decebc8ded9 0 oldest_to_newest 652914 0 kde-2011.08 2008-10-12 02:33:30 +0000 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). 731702 1 kde-2011.08 2009-03-17 15:09:05 +0000 Confirmed in KDE 4.2 1143741 2 dhaumann 2011-07-20 07:00:42 +0000 Is that still the case? 1143827 3 kde-2011.08 2011-07-20 13:18:24 +0000 Yes, this is still the case on Kate Version 3.6.5 Using KDE Development Platform 4.6.5 1311874 4 christoph 2012-11-02 22:46:25 +0000 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 *** 1311952 5 kde-2011.08 2012-11-03 08:50:43 +0000 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. 1312064 6 kde-2011.08 2012-11-03 15:24:32 +0000 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. 1314046 7 elcuco 2012-11-09 21:21:50 +0000 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 1314303 8 kde-2011.08 2012-11-10 18:20:51 +0000 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. 1389652 9 dhaumann 2013-08-14 10:00:34 +0000 Diego, any further comments on this? 1390295 10 zayed.alsaidi 2013-08-16 18:10:07 +0000 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. 1472638 11 christoph 2014-09-23 19:22:45 +0000 Is that now ok the way it is or not? ;) 1473567 12 kde-2011.08 2014-09-29 09:09:06 +0000 @Christoph: No, the situation today is exactly as it was in the OP. 1967948 13 justin.zobel 2020-10-25 07:21:52 +0000 Dotan can you please confirm if this is still an issue in Kate from KDE5. 1973079 14 bug-janitor 2020-11-09 04:33:37 +0000 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! 1973226 15 kde-2011.08 2020-11-09 12:21:47 +0000 @Justin Zobel: No, the situation today is exactly as it was in the OP. 1973227 16 kde-2011.08 2020-11-09 12:22:26 +0000 @Justin Zobel: No, the situation today is exactly as it was in the OP. 2219094 17 bug-janitor 2023-03-29 11:49:17 +0000 A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/532 2219202 18 christoph 2023-03-29 19:42:14 +0000 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 2219222 19 kde-2011.08 2023-03-29 22:46:41 +0000 (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. 2220314 20 waqar.17a 2023-04-04 19:34:04 +0000 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