The whole time the text cursor blinks at a rate of approximately -as fast as possible- and it's driving me *MAD*. It also makes concentrating on the file impossible, unless i focus some other part of the application or another window. Reproducible: Always Steps to Reproduce: 1. Open a file with okteta. 2. Make sure focus is on the editing widget. Actual Results: Loss of sanity. Cursor blinks at insane rate as long as focus stays on the editing widget. Expected Results: Being able to work. Cursor not blinking. I suggest to destroy all code that makes the cursor blink in okteta and all underlying librarys as well as any git history that could make it reappear. Also, i wish for an internatianal law that would make "enabling a blinking cursor by default" illegal. But making it configureable is an acceptable sollution, too... i guess... Okteta version is 0.13 - that was not on the list. I'm using KUbuntu 14.04, but the problem has been around for at least a year - sorry i didn't report it earlier. Personaly, i would rate the severity "Grave", but i guess this isn't what the majority would think.
Why don't you just change the cursor blinking rate?
(In reply to comment #1) > Why don't you just change the cursor blinking rate? How would i do that? Before submitting this bug report, i looked through the okteta menu for a way to do just that at least 4 times.
The blink speed is global for all Qt applications: qtconfig > Interface > Cursor Flash Time.
Hi Marek, thanks for reporting your problem. Hopefully you have not yet turned completely mad :) Having a non-blinking cursor is an interesting idea, never thought of that, as I am somehow used to blinking cursors as indicator which one is active. But interestingly enough the cursor in the browser text field I am just typing is not blinking. Hm... Back to your problem. While Okteta does some custom rendering of the view and thus also the cursor, it also uses QApplication::cursorFlashTime() to request the frequency of the cursor blinking, for consistency with the rest of the Qt apps (and hopefully the platform/system in general). Never heard of a similar problem. What value did/do you see in the qtconfig menu Christoph pointed to? (1000 ms for me)
(In reply to comment #4) > Hi Marek, Hm, autocompletion or something changed "Arek" to "Marek", sorry, only noticed now.
(In reply to comment #3) > The blink speed is global for all Qt applications: qtconfig > Interface > > Cursor Flash Time. Thanks - i found it now. Unfortunetly that didn't help me stopping the cursor from blinking. My setting was "no blinking". Setting it to something else changes the blink rate in okteta to something less evil, but also makes all other applications blink :(. (In reply to comment #4) > thanks for reporting your problem. Hopefully you have not yet turned > completely mad :) Nope, still sane :)... although... i wouldn't know if i was mad, right? Damn... i just hope for the best ;) > Back to your problem. While Okteta does some custom rendering of the view > and thus also the cursor, it also uses QApplication::cursorFlashTime() to > request the frequency of the cursor blinking, for consistency with the rest > of the Qt apps (and hopefully the platform/system in general). Never heard > of a similar problem. What value did/do you see in the qtconfig menu > Christoph pointed to? (1000 ms for me) It was set to "no blinking", which is translated to 0. I assume you have something like this in the source code: const int minBlink = 1; const int maxBlink = 2000; // because setting it higher doesn't have any effect... if (QApplication::cursorFlashTime() < minBlink) flashTime = minBlink; if (QApplication::cursorFlashTime() > maxBlink) flashTime = maxBlink; Am i right here? At least this would explain the flashing rate. Now, for consistency, you might want to set maxBlink to 10000, which is the maximum in qtconfig. Or probably even better: just abandon the check! (because qt probably already checks it for < 0 and the documentation says "We recommend that widgets do not cache this value as it may change at any time if the user changes the global desktop settings.") Just setting minBlink to 0 on the other hand probably wont solve the problem. In part because, as I noticed, blinking means that the background color becomes the foreground color at the cursor, making it unreadable when not blinking. Could you simply swap foreground and background colors? Then, if my assumptions are right, you only need to do something like the following to make it work: if (QApplication::cursorFlashTime() > 0) { //blink code } (In reply to comment #5) > (In reply to comment #4) > > Hi Marek, > > Hm, autocompletion or something changed "Arek" to "Marek", sorry, only > noticed now. No problem.
Yep, there are actually two bugs here. First, Okteta doesn't respect disabled cursor flashing (when cursorFlashTime() is 0). It should only fire the timer if the value is > 10 (that's what qt-config uses). Second, just disabling blinking makes the text behind the cursor unreadable because of color choice as mentioned in comment #6.
Bump! 2 Years later and still not fixed :( While there is still no way to easily turn off blinking in qt5 on linux (shame on that!), it can be done with qt5noblink (https://github.com/igogo/qt5noblink). While this works for other applications, okteta (0.17.0 here) still blinks insanely.
In file ~/.config/kdeglobals, disabling cursor blinking by setting: [KDE] CursorBlinkRate=0 causes Okteta to blink as fast a possible chewing up 100% of a single CPU core. I've switched to ghex for now to avoid the problem, but if this gets fixed I'd happily move back to using okteta as it has more features. Thanks,
I can confirm this issue still exists in Okteta 0.26.4 on Debian Bullseye -- quite a visual nuisance for those who are disturbed by blinking cursors in general.
A possibly relevant merge request was started @ https://invent.kde.org/utilities/okteta/-/merge_requests/6
@aguzinski Hi (and Happy New Year). Thanks for going the extra miles to come up with a patch to solve that issue with the missing support for non-blinking cursor. While I had that bug in the back of my mind, my memory also was that there had been some unresolved discussion about what to do for the non-blinking cursor rendering when it comes to the insertion state cursor: the shadow cursor marking the same spot in the non-input receiving half (char or values) would be only hard to distinguish (1 pixel line width vs. 2 pixel line width) from the active cursor. But this bug report does not have any related comment, so it might have been some other place or my memory just made this up from other similar things :) In any case, you are triggering me to revisit this problem now. Having the cursor rendering the inverted symbol is actually also an improvement for anyone (and adds consistency with text cursors in other apps). Perhaps this was different at the time when I wrote that logic, I think I tried to be consistent at the time as well :) Seeing your patch I assume that the mentioned issue for the insertion cursor is less grave and having a non-blinking cursor at all is already an improvement (and not affecting any people who prefer the blinking cursor). So fine with me to just support non-blinking cursor for now by just drawing the current cursor shape (updated with color-inverted data). Both things should be added in the next days and be part of the planned 0.26.5 release (so far a mere translations update) in the second week of January 2021. Now, any ideas how to approach the non-blinking cursor in the insertion variant?
And a happy new year to you! I'm glad my work got this rolling :) As far as the insertion mode is concerned... I comletely forgot about it, but on a second look, I see what you mean. From my point of view, "difficult to distinguish in a rarely used mode" is a major improvement from "practicaly unusable". I gave the insertion mode problem some consideration, and can think of 2 possible solutions (although none of them feels perfect). One would be to draw a 2 pixel in fg-color, 2 pixel bg-color alternating line around the block (I'll attach a mockup). The other might be to highlight the line in the active subview (like the active line in kate). I also noticed 2 related minor problems: * the insertion cursor overlaps with the value a bit too much - I think it would be better to draw it a pixel more to the left (see second mockup for comparison).. maybe even 2 pixels. * Directly after switching between insert and overwrite mode, the cursor is not drawn at all until you move it. I believe this is because drawing the cursor is so tightly coupled to the blinking timer. I haven't found them yet, but can imagine that there are other cases where this happens.
Created attachment 134565 [details] possible solution for insertion cursor problem
Created attachment 134566 [details] the above, with cursor slightly more to the left
(In reply to Arek Guzinski from comment #13) > And a happy new year to you! > > I'm glad my work got this rolling :) And still is rolling, though more slowly, but passing first milestones now... > As far as the insertion mode is concerned... I comletely forgot about it, > but on a second look, I see what you mean. From my point of view, "difficult > to distinguish in a rarely used mode" is a major improvement from > "practicaly unusable". Okay, so that unsolved problem will not be a blocker, agreed. One step by the time gets us forwards in the end. > I gave the insertion mode problem some consideration, and can think of 2 > possible solutions (although none of them feels perfect). > One would be to draw a 2 pixel in fg-color, 2 pixel bg-color alternating > line around the block (I'll attach a mockup). > The other might be to highlight the line in the active subview (like the > active line in kate). Thanks for the ideas. I split that issue of into a new bug 432209, for further discussion by the time (no immediate thoughts myself so far). > I also noticed 2 related minor problems: > > * the insertion cursor overlaps with the value a bit too much - I think it > would be better to draw it a pixel more to the left (see second mockup for > comparison).. maybe even 2 pixels. Forked that off into a new bug 432211. No immediate opinion, need to play with that later this year. > * Directly after switching between insert and overwrite mode, the cursor is > not drawn at all until you move it. I believe this is because drawing the > cursor is so tightly coupled to the blinking timer. I haven't found them > yet, but can imagine that there are other cases where this happens. Any chance that happened due to some patches you have? Because I cannot reproduce that, and the code logic should actually ensure that after any change the initial blink cursor state is visible/on. Please try again with an unpatched version, either some older or the latest code from the repo, once I pushed my commits for adding support for flashTime==0 in the next hours. Brushing up my testing code finally into proper commits now to now land them and close the initially reported bug. Glad to see you a committed user even after 7 years with this experienced-as-grave bug, and hopefully a more happy user in the future with okteta-as-out-of-the-box (and making other silent non-blink-preferring co-users happy as well).
Git commit 2918cc6a5607b1505de0c0f1885aada8b863e8c4 by Friedrich W. H. Kossebau. Committed on 27/01/2021 at 17:43. Pushed by kossebau into branch '0.26'. Support cursor flashtime setting of 0 (= no blinking) The insert cursor and end-of-line cursor shapes need more work to tell normal and shadow cursor apart from each other, left for later. FIXED-IN: 0.26.5 M +8 -2 gui/abstractbytearrayview_p.cpp M +3 -1 gui/abstractbytearrayview_p.hpp https://invent.kde.org/utilities/okteta/commit/2918cc6a5607b1505de0c0f1885aada8b863e8c4
And back again ^^ - had a lot of distraction lately... >> * Directly after switching between insert and overwrite mode, the cursor is >> not drawn at all until you move it. I believe this is because drawing the >> cursor is so tightly coupled to the blinking timer. I haven't found them >> yet, but can imagine that there are other cases where this happens. > Any chance that happened due to some patches you have? Because I > cannotreproduce that, and the code logic should actually ensure that after > any change the initial blink cursor state is visible/on. Well... probably... I tried it with the current package in neon and can't reproduce it either :) One more thing I noticed (which might be intended?): If the keyboard focus is anywhere except the editing part or the decoding table, the cursor is invisible.