GNOME Bugzilla – Bug 334060
Selection in text is in sync with PRIMARY clipboard
Last modified: 2015-12-22 08:17:16 UTC
Text in text widgets (GtkTextView, GtkEntry) gets unselected when another application or widget acquires primary selection. That happens in particular when any text is selected in another application/widget. This is wrong for the following reasons: 1) I (replace with "user", of those who don't care about primary selection) do not want selection to disappear unless I unselect it by click or cursor move or something. 2) It causes #333320. I don't know why gtk_clipboard_set fails on my computer in that case, but I am certain that I do not want to be forced to use ctrl-L in FileChooser dialogs because of some misterious clipboards. I propose to introduce a gtk setting for this: "selection-is-primary", FALSE by default. If it's TRUE, let gtk behave as it does now. If it's FALSE, let newly selected text steal primary, so that "select, switch and press middle mouse button" still works; but selected text should not get unselected if someone else acquires PRIMARY. Yes, it would mean that "selected text != primary selection content", i.e. it would do what mozilla does. But this is way smaller problem when unselecting text nobody (at least not a normal human who is editing text in gtk application and opens a dialog with an entry inside) knows why. Not acquiring PRIMARY at all would be wrong because 'select and use middle button' is a nice feature, and there is no reason to remove it, as long as it doesn't cause troubles in normal operations. FALSE by default because majority of people do not care about primary selection at all, and do not understand why highlighting in text disappears. Would such a patch be accepted?
No. You cannot fix problematic behaviour by making it configurable and asking the user to unfix it themselves.
No, I am proposing to make it configurable for those who want problematic behaviour. I'd like to change this thing without adding any settings, but there are many people who really like gtk text widgets behaving as xterm, and it wouldn't be good to remove what they like completely. Usual people wouldn't configure anything, and would have "selected text == whatever I selected" mode.
The authoritative source for X clipboard behaviour is http://webcvs.freedesktop.org/icccm-extensions/selections/clipboards.txt?rev=1.2&view=markup I would recommend to debug why you are seeing different behaviour than the rest of us, before proposing workarounds.
Please see reason number 1). Let me stress it: gtk behaviour is buggy! It unselects my text when I don't ask it to, I can't have text selected in two widgets simultanelously. It was my mistake that I put 2) in this bug report, please discard it (though I still think it's GTK clipboard thing that doesn't let me use FileChooser: why should I depend on PRIMARY clipboard when I type path in? What if I like some process stealing primary selection? What if I want to control primary selection content, so I could paste with middle button what I need? The only argument is that "PRIMARY must be in sync with text selection", but it's exactly what I do not agree with). As a side note, I hacked this around in my editor, and I love the do-not-unselect-it-if-not-told-to behaviour. And I am not the only one who likes it!
There is nothing buggy about having a single visible selection. The main premise of PRIMARY is that it always corresponds to the visible selection. Note that the selection is actually per-buffer, not per-view, and we do show the selection in all views associated with a buffer. Which seems to be the thing you want to generalize to allow every widget to have its own selection simultaneously (and have the selection of the focus widget correspond to PRIMARY) Also note 333514, which is another bug which claims GTK+s clipboard handling is buggy.
Another side note: may I please have location entry back in FileChooser, ig(In reply to comment #5) > There is nothing buggy about having a single visible selection. This is what I do not agree with. I want to be able to have many visible selections. E.g. I want to select text, switch to other application/widget, switch back and find my selection untouched. Etc., etc. The current gtk behaviour is wrong for me, and this is why I'm saying it's a bug. > The main premise of PRIMARY is that it always corresponds to the > visible selection. This implies having single visible selection, therefore it's not relevant if I want many selections. > Note that the selection is actually per-buffer, not per-view, and > we do show the selection in all views associated with a buffer. > Which seems to be the thing you want to generalize to allow every > widget to have its own selection simultaneously (and have the > selection of the focus widget correspond to PRIMARY) Well, fact that GtkTextView's selection is per-buffer is a separate GtkTextView bug. My main concern is: "do not remove my selection when I select text elsewhere". Buggy one-buffer-two-textviews behavior is better than what we have now (*for me and those who want multiple selections*). > Also note 333514, which is another bug which claims GTK+s clipboard > handling is buggy. That bug report is about the fact that PRIMARY is cleared when text is unselected. It's completely separate problem.
Created attachment 61004 [details] [review] gtk-unselect-on-clear-clipboard setting Here's the patch adding such a setting. All that it does is checking the setting before unselecting text in GtkLabel, GtkEntry; and before calling gtk_text_buffer_add_selection_clipboard in GtkTextView code.
Oh, what I did doesn't acquire PRIMARY on selecting text in GtkTextView (so more nasty code should be added to gtktextbuffer.c). But you can get the idea. About GtkTextBuffer: now I really understand problem from #5. If there are two views on different screens, and this setting has different values on those screens, what should buffer do? But well, this is one more argument against having selection in the buffer instead of the view (fact that it's impossible to implementation details is a different matter).
Lets keep the file chooser out of this bug, can we ? > > The main premise of PRIMARY is that it always corresponds to the > > visible selection. > > This implies having single visible selection, therefore it's not relevant if I > want many selections. Not necessarily. I said a single _visible_ selection. Widgets could still keep there selection around, and show it when they get focus again. Or maybe even show it in a different way (like unfocused text views do currently) > Well, fact that GtkTextView's selection is per-buffer is a separate > GtkTextView bug. Not every design decision you disagree with is a bug. > That bug report is about the fact that PRIMARY is cleared when text is > unselected. It's completely separate problem. No, its highly related. Both are outcomes of the current strict interpretation of a 1-1 relation between GTK+ selection and PRIMARY.
(In reply to comment #9) > Lets keep the file chooser out of this bug, can we ? Sure. > Not necessarily. I said a single _visible_ selection. Widgets could still keep > there selection around, and show it when they get focus again. Or maybe even > show it in a different way (like unfocused text views do currently) This would be wrong - imagine you see the textview in background. You click it and selection magically appears. It would be confusing, and well, what's the point? Why "single visible selection"? Why not just many? > > Well, fact that GtkTextView's selection is per-buffer is a separate > > GtkTextView bug. > > Not every design decision you disagree with is a bug. It's not only my personal opinion. People in bugzilla say it's a bug; people working with text widget say it's a bug. But of course it's irrelevant here. > > That bug report is about the fact that PRIMARY is cleared when text is > > unselected. It's completely separate problem. > > No, its highly related. Both are outcomes of the current strict interpretation > of a 1-1 relation between GTK+ selection and PRIMARY. It is related, and it's very closely related to this issue if one considers ways to change how selection and clipboards work. But my main point is *having multiple text selections* (visible!). I would even choose no PRIMARY support, if I could get multiple selections, since multiple selections are very important for editing text. Having newly selected text be placed into PRIMARY clipboard would be a bonus, and would require minimal changing to gtk if one fixes this bug (or implements this feature, or whatever one calls it). So I propose doing what I propose and having better behavior than we have now. It will not break stuff, and that bug can be fixed (or not fixed) independently, since I do propose having new selections steal PRIMARY, i.e. I propose only make *unselecting on clearing PRIMARY* optional.
Created attachment 61006 [details] [review] updated patch
Created attachment 61411 [details] test helper Try to run this program, and then select some text in gedit. Yes, this program grabs PRIMARY, but what does it have to do with selecting text in gedit? (with selecting text to put it into PRIMARY - yes, but what about highlighting some text to copy it to the clipboard?)
Thread in usability list: http://mail.gnome.org/archives/usability/2006-March/msg00130.html
(In reply to comment #9) > Not necessarily. I said a single _visible_ selection. Widgets could still keep > there selection around, and show it when they get focus again. Or maybe even > show it in a different way (like unfocused text views do currently) This is a good point. Users want applications to preserve their state, including anything that might be selected. Geeks want PRIMARY, the most recent selection, to be clearly differentiated from anything else. Preserving other selected text, but showing it differently, would seem to satisfy both requirements, and there'd be no need for an extra config option.
(In reply to comment #14) > Users want applications to preserve their state, including anything that might > be selected. > Geeks want PRIMARY, the most recent selection, to be clearly differentiated > from anything else. > > Preserving other selected text, but showing it differently, would seem to > satisfy both requirements, and there'd be no need for an extra config option. How exactly would it look like? All I can think of is using different colors, and it would be super ugly (imagine two windows with selected text and you switch between them).
If I have Gedit in the foreground, the selection there is coloured according to my theme. Firefox remembers selected text, and if it's in the background the selection is grey. You change it so that instead of the selection in the current window being coloured, it's the PRIMARY that is coloured, and others are grey. It might seem a little unusual when you switch to another window with a selection and PRIMARY is elsewhere, but as soon as you select something there, you get the colour back again. And it might help people learn about it too. Maybe ask again on the usability list, to see what people think of this sort of idea?
Consider also Nautilus: each window has its own selection. Windows in the background have a selection in grey. The foreground window has a selection of the current theme highlight colour.
This was discussed quite a bit on Bug 333514. That bug report deals with entirely too many issues. Any future discussion should happen on this bug report, but note that there's quite a few comments there that interested parties might wish to read.
time to close this