[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 --- Comment #8 from Arek Guzinski --- 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. -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 Bug Janitor Service changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #11 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/utilities/okteta/-/merge_requests/6 -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 --- Comment #12 from Friedrich W. H. Kossebau --- @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? -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 Harrison Smith changed: What|Removed |Added CC||harri...@htsmi.net --- Comment #10 from Harrison Smith --- 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. -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 chris-pi...@uiowa.edu changed: What|Removed |Added CC||chris-pi...@uiowa.edu --- Comment #9 from chris-pi...@uiowa.edu --- 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, -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 --- Comment #18 from Arek Guzinski --- 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. -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 --- Comment #13 from Arek Guzinski --- 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. -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 --- Comment #14 from Arek Guzinski --- Created attachment 134565 --> https://bugs.kde.org/attachment.cgi?id=134565&action=edit possible solution for insertion cursor problem -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 --- Comment #15 from Arek Guzinski --- Created attachment 134566 --> https://bugs.kde.org/attachment.cgi?id=134566&action=edit the above, with cursor slightly more to the left -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 --- Comment #16 from Friedrich W. H. Kossebau --- (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). -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 Friedrich W. H. Kossebau changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Version Fixed In||0.26.5 Latest Commit||https://invent.kde.org/util ||ities/okteta/commit/2918cc6 ||a5607b1505de0c0f1885aada8b8 ||63e8c4 --- Comment #17 from Friedrich W. H. Kossebau --- 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-2gui/abstractbytearrayview_p.cpp M +3-1gui/abstractbytearrayview_p.hpp https://invent.kde.org/utilities/okteta/commit/2918cc6a5607b1505de0c0f1885aada8b863e8c4 -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336607] cursor is blinking (flashing) at insane rate
https://bugs.kde.org/show_bug.cgi?id=336607 --- Comment #8 from Arek Guzinski --- 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. -- You are receiving this mail because: You are watching all bug changes.
