Version: unspecified (using KDE 4.4.2) OS: Linux When selecting text in a new window, the selection in the previous window stays highlighted, which is confusing when coming back later, because you never know what will be pasted. Reproducible: Always Steps to Reproduce: 1. Open 2 konsoles (or other windows) 2. Using ls (or other commands), cause test to appear in each 3. Select a bunch of text in first konsole 4. Select a bunch of text in second konsole Actual Results: Text in first konsole is still show as selected. A paste will paste the text selected in second konsole Expected Results: After losing selection, the first konsole (or other app) should no longer show the text as highlighted. It's not just konsole but also firefox, emacs, ... Changing selection within a same window works as expected (previous selection no longer highlighted) The problem has already been occurring for some time
the client is informed. the problem is on the clients side on how to deal with this. (color changes, etc.) so regarding kwin this bug is invalid. you could file a bug to either konsole, or kdelibs or Qt, BUT: gtk+, java and even xterm don't act any different (i doubt any toolkit does) personally i'd say esp. this behaviour would be rather annoying then helpful (as on cnp from one window to another you could not re-check the selection), but then again: this is not a kwin thing.
You're right. Indeed, on xterm, it works (correctly shows when selection is lost). So it must probably be the Toolkit. Weird however that emacs is affected as well. Sorry didn't understand the part between parenthesis in the last sentence, what is cnp? It did definately work a while back (couple of years), but I can't unfortunately say when it broke.
emacs can use an/the X toolkit and is then unrelated to the terminal. even iff, it could keep paint ing whatever it wants (i doubt it just uses the terminal selection) what i meant on "cnp" is that when Copy-aNd-Pasting stuff from one window to another it can be rather annoyin to loose the selection hint on the inactive window as you cannot check it before pasting. that's however personal preference. notice that Qt supports a stylehint that allows to alter the selection color (fade to grey in doubt) of unfocussed elements
[emacs]: yeah, indeed each app could ignore whatever hint it gets from the WM, and paint whatever it wants... it's just weird that almost all apps (with the exception of xterm, where it still works) would all misbehave in the same way. [About cnp]: Maybe there is a misunderstanding here. I'm talking about the situation where the selection _has_ already been lost, but where this isn't show in the (former selection source's) UI... making this indication more or less useless for checking before pasting (because it may be wrong). I agree, under normal circumstances this is probably not an issue (as you probably know what you selected), but things get iffy if you get distracted (phone-call, etc.), and later intend to pick up where you left off, but the UI gives you an out-of-date picture. Same thing if you accidentally lose the selection by clicking on one window to bring it to foreground: the UI won't warn you, and you wonder why you paste empty text.
(In reply to comment #4) > [About cnp]: Maybe there is a misunderstanding here. I'm talking about the > situation where the selection _has_ already been lost, you mean on the X11 level (for mmb clicking, you already selected sth. in another window) - yes. however not internally from the clients POV and ctrl+c/p handling, what is probably the more common case as of today. (also this would actually require a protocol extension. (while i frankly don't know whether this is already part of some X11 extension) the X server needs to set some hint on the currently X11 selection holding client (so that the client can react) this is however unrelated to the window activation state - so no WM job either, though.
> however not internally from the clients POV and ctrl+c/p handling, what is > probably the more common case as of today. Couldn't this be made configurable via some option, for people who don't need ctrl+c/p handling? > also this would actually require a protocol extension. Why would it? It used to work. And it still works for some apps (xterm). > the X server needs to set some hint on the currently X11 selection holding > client (so that the client can react) Well the X server (or whatever other component) used to do just this. And apparently still does for some apps (such as xterm). > this is however unrelated to the window activation state - so no WM job > either, though. So which component would be the most appropriate to report this bug on? Each application or toolkit? Or the X server? How can I find out whether the "selection lost" message is simply not being sent (by whoever is responsible for doing so), or whether it that message is being ignored by the application? If it is the toolkit, which would this be in the case of KDE apps (konsole, etc.). Would it be Qt, or some KDE-specific library? Thanks
(In reply to comment #6) > Couldn't this be made configurable via some option, for people who don't need > ctrl+c/p handling? toolkit issue. > So which component would be the most appropriate to report this bug on? Each > application or toolkit? Toolkit. On a little investigation, Qt known QClipboard that provides the required signal - it would have to be connected to some slot on QTextEdit and others to update the selection painting. However you'll run into the ctrl+c/p conflict (eg. select some block, select another block in another window, copy that and paste it overriding the first block). also neither windows nor mac support this at all, so prepare for some discussion. I passed this over to konsole as it seems your most important item.
Thanks for the info. So, basically, to sum it up, Qt provides the necessary signal (so it does its part), but it's the application (each application) which ignores it? Well, if I was happy with windows, I'd use windows. Unix/Linux is supposed to be superior. Or at least it used to be. So somehow I feel that "windows doesn't provide it" should not be an argument. But maybe a compromise would be to change the color ("selected" block still highlighted, but in light grey instead of black). Konsole would indeed be the prime candidate for this (thanks for passing it over), but web browsers, such as konqueror, are also important. Very often I copy text from web pages.
to be more precise: each text presenting class needed to connect to this slot (mostly QTextEdit, QLineEdit, but Konsole and khtml/webkit have different opinions - this won't fix applications like firefox or thunderbird, though - and they can not rely on the Qt functionality of course)
The requested behavior is not hard to implement in Konsole(I made a quick experiment), but I do not like it: 1). It cause some minor side effects. For example, select something in tab #1, then switch to tab #2 and select something, then the color of tab #1 will change which indicates activity within tab #1 while there is actually no activity there. Of course, this is really an implementation problem which can be solved. 2). Even if we put extra effort to make the implementation better, there is still the issue of consistency with other KDE apps. From my observation, most Qt/KDE apps behave in the reported way, while most gtk/gnome apps behave in the requested way. I do not think it is a good idea for Konsole to behave differently as long as it is still part of KDE. 3). Even if we put the consistency issue aside, we still have the problem of "which behavior is better from the point view of users?". Since this report do not have many votes or comments, I guess most users like current behavior or simply do not care. Make the behavior configurable? I think that is overkill, since the current behavior is not a problem in most conditions. Just my 2 cents.
Regarding #1: well yes, as you yourself suggested in #2, the obvious solution would be to not consider loss of selection as "activity". Regarding #2: it _is_ actually a problem in the other KDE apps as well (and some non-KDE apps too). Konsole was just one example. I guess that means that _all_ of them should be fixed, hopefully in kdelibs... Regarding #3: why was it even changed at all? What advantage does the current behavior have over the previous one? Do we have _any_ evidence of even one _user_ who prefers the current behavior? If so, for what reason? If users suddenly started commenting "en masse" they would be accused of being disruptive (just look at what happens on the mozilla boards for popular bugs). Maybe the reason for their silence is because it is a relatively "simple" bug, and there is not that much more to add? Or nobody took the time for searching for this bug? I must admit, I for myself had noticed this behaviour since quite a while already before taking the time to write this bug report up. It's nothing major, but one of the many relatively minor annoyances that slowly,and little by little, make Linux less pleasant to use.
Well, you are welcome to open requests for kdelibs and Qt to change current behavior in all related UI components. I'm glad to do extra coding to make Konsole follow after that kind of change happens , but I'm not intended to make Konsole take the lead. As for the annoyance, I thing that is quite subjective. I myself find the requested behavior very annoying when using gnome-termianl (Yes, I do use it sometimes) and other gtk3 applications. And I'm not the only one who holds that idea[1]. [1] https://bugs.archlinux.org/task/24290
I'm not sure I understand your bug report on gnome-terminal In step 2, you explicitly make another selection. So what did you expect to happen? Adding to previous selection rather than replacing it? Or what? In any case, in konsole the selection is lost too, but the display doesn't reflect that fact. And that's the problem: that the display gets out of sync with what happens. Btw, the converse happens too: if you select some text in a konsole, then paste it within same, the originally selected text is no longer highlighted, even though it is still selected. Weird...
"selecting something in tab A or another application clears the selection in tab B", that is what gnome-terminal does, what you want kosole to do and what that reporter and I find annoying. "Btw, the converse happens too: if you select some text in a konsole, then paste it within same, the originally selected text is no longer highlighted, even though it is still selected", that looks like a bug to me. I will take a look .
(In reply to comment #14) > "selecting something in tab A or another application clears the selection in > tab B", that is what gnome-terminal does, what you want kosole to do and > what that reporter and I find annoying. I'm afraid I still don't understand. Konsole loses the selection too if you take it away (by making a new selection elsewhere), only its display doesn't reflect this fact. What I want is that the display does reflect the loss of selection, so as to not be misleading. Do you really find it annoying if the display reflects the actual loss of selection? Or is it something else? > > "Btw, the converse happens too: if you select some text in a konsole, then > paste it within same, the originally selected text is no longer highlighted, > even though it is still selected", that looks like a bug to me. I will take > a look . Good, thanks
(In reply to comment #15) > (In reply to comment #14) > > "selecting something in tab A or another application clears the selection in > > tab B", that is what gnome-terminal does, what you want kosole to do and > > what that reporter and I find annoying. > > I'm afraid I still don't understand. Konsole loses the selection too if you > take it away (by making a new selection elsewhere), only its display doesn't > reflect this fact. What I want is that the display does reflect the loss of > selection, so as to not be misleading. Do you really find it annoying if the > display reflects the actual loss of selection? Or is it something else? > Select something in the same tab, the old selection in the same tab should definitely disappear. That is what konsole and gnome-terminal do. Select something in tab A or another application, gnome-terminal clears the old selection in tab B. konsole does not. If you switch to tab B later, the old selection is still there and the "Copy" action will copy the selected text into clipboard as expected. The reason I find the requested way annoying is selecting something is a boring task and I hate to do it again and again just because I (accidently) select something in another window or tab.
I think this discussion derives from a fundamentally different sight on CNP The "traditional" mmb way is rather X11 exclusive and even there the majority of user will not even know about and stick to common ctrl+c, ctrl+v - therfore it makes much sense to keep selections until they're explicitly cleared to permit reusage. Unfortunately the way to push to the mmb clipboard is usually the same as for the ctrl+c,v clipboard, so QClipboard::selectionChanged() will fire "too often" (because it's not predictable what buffer the user has in mind) What might be a more reliable solution would be a dedicated hint for the current clipboard content (could be some klipper (shortcut? triggered) "tooltip" but also some plasmoid or wherever you got place to show it) - this would implicitly cover all applications (i doubt Qt/KDE has *ever* behaved differently)
Git commit 2a92a3a7c282694ad9e6fb96cd57a71c1c41958b by Jekyll Wu. Committed on 07/05/2012 at 18:44. Pushed by jekyllwu into branch 'master'. Do not clear selection after pasting. The old behavior has a long history, initially introduced by commit 1e3c3e27 more than 10 years ago. I fail to understand its intention (some safeguard?), and I think keeping the selection is more useful in work flow. Keep it in master branch for now. No backporting. M +0 -2 src/TerminalDisplay.cpp http://commits.kde.org/konsole/2a92a3a7c282694ad9e6fb96cd57a71c1c41958b
(In reply to comment #16) > Select something in the same tab, the old selection in the same tab should > definitely disappear. That is what konsole and gnome-terminal do. > > Select something in tab A or another application, gnome-terminal clears the > old selection in tab B. konsole does not. If you switch to tab B later, the > old selection is still there and the "Copy" action will copy the selected > text into clipboard as expected. No, it copies the new selection, that's the point. And (IMHO), this is good, or else copying from one app to another would be a pain, if the target app happened to have an old selection...
(In reply to comment #19) > (In reply to comment #16) > > Select something in the same tab, the old selection in the same tab should > > definitely disappear. That is what konsole and gnome-terminal do. > > > > Select something in tab A or another application, gnome-terminal clears the > > old selection in tab B. konsole does not. If you switch to tab B later, the > > old selection is still there and the "Copy" action will copy the selected > > text into clipboard as expected. > > No, it copies the new selection, that's the point. And (IMHO), this is good, > or else copying from one app to another would be a pain, if the target app > happened to have an old selection... Please note I am talking the explicit "Copy" action provided by konsole , not the implicit mouse middle click. And your seems to be talking about pasting into konsole, not copying from konsole.
Bug still present, more than 11 years after reported, after spreading like a cancer to (almost) everywhere :-( xterm still safe, but I guess it'll only be a matter of time.