https://bugs.kde.org/show_bug.cgi?id=336607
--- Comment #16 from Friedrich W. H. Kossebau <kosse...@kde.org> --- (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.
