https://bugs.kde.org/show_bug.cgi?id=412516
--- Comment #4 from David C. Bryant <davidbry...@gvtc.com> --- (In reply to Christoph Cullmann from comment #3) > No, I didn't imply that you need to compile that stuff, just wanted to know > if you can try with a more up-to-date version. > > But you did that already given you state below > SUSE LEAP 15.1 (Plasma 5.12.8 Frameworks 5.55.0 Qt 5.9.7) > Neon 5.16.4 (Plasma 5.16.5 Frameworks 5.62.0 Qt 5.13.1) > SUSE LEAP 15.1 (Plasma 5.12.8 Frameworks 5.55.0 Qt 5.9.7) > Debian 10.0 (Plasma 5.14.5 Frameworks 5.54.0 Qt 5.11.3) > > I would really like to fix this, but after inspecting the code a bit, I > can't think of any "obvious" reason this should happen :( I honestly doubt that the problem is in Kate itself. But I had to report it somewhere if I wanted to report it at all. Let me explain. About a year ago I noticed a change in the way the "Clipboard" works. Previously (on SUSE LEAP 42.3, and going all the way back to SUSE 9.0, starting in 2003) I could select a block of text in just about any program whatsoever, and it would not be copied to the "Clipboard" until I hit ^C, or ^X. When I installed LEAP 15.0 (December, 2018) I noticed a change. Text was automatically copied to the "Clipboard" as soon as it was highlighted (either by dragging the mouse, or by holding Shift and striking --> on the keyboard). This was very annoying for a while, because I had been in the habit, when surfing the web, of selecting a URL somewhere (with the right-click context menu in Firefox --> Copy Link Location) and then pasting it in the navigation bar of a Firefox tab that was already open. The new behavior of the "Clipboard" made this procedure more difficult, because when I selected the text I wanted to replace with the copied URL, a new entry was made in the "Clipboard"'s stack of saved items, effectively erasing the new data I was trying to copy. So I had to either open the "Clipboard" from the system tray and move the data I wanted to copy back to the top of the stack, or alter my old habits and erase the text I wanted to replace (with backspace, or delete) instead of just selecting it and then overwriting it with ^V. The new procedure wasn't any more work than the old procedure, but old habits are hard to break. I still have trouble with the recent change in "Clipboard" behavior. Anyway, I don't have the trouble with Gnome programs like gedit (I have configured both Debian and SUSE with multiple desktops on my new PC). I don't log into the Gnome environment very often, because I've used KDE since 2003, and I'm used to it. But I can invoke gedit from either desktop. Anyway, the "Clipboard" is different in Gnome -- I don't think there's a stack of saved items in that environment, because there isn't any system tray. At a minimum, if there is a stack, I don't know where to find it. To make a long story short, I suspect that KDE sticks its "hooks" pretty deep into the Linux / X11 environment to maintain the stack of items on the "Clipboard" that appears in the system tray, because ^C and ^X work just about the same way in every program that runs (including things like LibreOffice, and Firefox). I'm not really an expert on Linux internals. But I wrote a lot of programs in assembler (almost machine language) on IBM mainframes, so I know that "system-wide" features can do unexpected things, because i/o interrupt routines are very hard to get exactly right. (^C and ^V cause interruption events, which are buffered inside the keyboard and passed through to the PIC / CPU on the motherboard at somewhat sporadic intervals, as I understand it.) Thanks again for helping, Christoph. If I think of something else that might be useful information, I'll report it here. -- You are receiving this mail because: You are watching all bug changes.
