I would like to ask a question about the strange behavior of GtkTextView and GtkEntry widgets. It seems that only one widget of these types can contain a selected area. Two typical scenarios:
(1) We have two text editors that use GtkTextView (or GtkSourceView) widgets. We select a piece of text in one editor and switch to another one. As long as we process the text in the second editor nothing happens in the first one. But once we have selected a piece of text in the second editor, the selection in the first, unfocused editor disappears.
(2) We select a piece of text in the main window of a text editor and then open the GtkFileChooserDialog in the Save File version. This dialog provides a GtkEntry field that contains the file name which is selected by default. Creating the dialog removes the selection in the main window of the text editor. The same effect occurs by using the Find dialog.
Removing selection does not mean that the selected text disappears but that the the state being selected is deleted. The standard mark “selection_bound” is moved to the position of the cursor (and the signal “mark-set” is emitted).
I see this effect in many different versions of one popular Linux distribution.
Is this a bug or a feature? If this is a feature, what is it good for? What is its purpose?
It’s the way all Linux has worked ever since I knew (12+ years). Are you suggesting other OSes have a different method of selecting things? Personally I would find that confusing, to have more than one selection at the same time.
Thank you for the response! This motivated me to study the situation a little more.
Not only Windows but also a Linux distribution with the KDE desktop behave in a different manner. In both, the only restriction is what happens within a dialog window: here, only one text entry (== edit control) can have selection. Apart from that there are no limitations. E.g., you can have two instances of the Kate text editor with selected areas. They are totally independent from each other.
If you run several Windows native applications on Linux with a GTK-based desktop (under Wine), then they also can have many selections simultaneously.
This restriction seems to be limited only to GTK-native applications. However, I haven’t checked what would happen with a KDE-application running on a Linux with a GTK-desktop (or vice versa).
Anyway, this selection singularity is not Linux-typical, but rather linked to a particular toolkit/framework.
Copy/paste operations are done on the currently focused widget. In this respect, there is no difference between having only one or many selections.
I think so. I’m on Gnome Shell and here have 2 Kate windows (qt5) at the top and below it 2 Text Editor windows (gtk4). In the Kate windows I can set a selection in each window. In the Text Editor windows when I set a selection in the 2nd window, it unsets the selection in the 1st window.
Thank you for sharing this experience! I have done some more research and now I begin to understand the situation. If I see it right, the X Window selection system allows the following task: (1) select a text in some program, (2) switch to another program, (3) copy the selected text to the latter program. And this without previous copying the text to the clipboard. If this is correct, then the selection singularity makes sense. BTW, this mechanism must be not the same as “lazy” pasting (the data, supposedly copied to the clipboard, is transferred only as long as the source application is opened).
However, the Wikipedia article about X Window selections claims that many selections are possible (“The X Window System supports an arbitrary number of selections…”), while one of them is the primary selection. If many selections are, at least theoretically, possible, then I do not understand how to distinguish between them. The wiki tries to explain this, but I was not able to follow the story…
Just leaving a comment here to say that “selection”, in the context of X11, does not mean “text selection”: a selection is just a shared buffer on the X11 server. Selections can be used to store data from one process, and retrieve it from another process—drag and drop and clipboard copy and pasting are implemented using selections.
Yes though I’m on Wayland, not X11. I don’t know which component implements it for me on Gnome Shell on Wayland, but I use what you outline above all the time Hence my confusion with setting multiple selections.
I was quite uncomfortable with this feature (selection singularity) until I got knowledge about its purpose. Now, I can change the design of programs in the way, that this feature is considered as a part of user interface and not as something only disturbing. BTW, this is not the first time that the X11-originated stuff surprises me.
I have explored how the KDE combines multiple selections with the middle button paste. Here, the selection made last is used for the paste operation. If this selection disappears (e.g. the window is closed), then the clipboard content is used. I had rather expected a kind of LIFO chain: if the last selection disappears, then the previous selection would be used.
In general, the KDE solution is not much different from the GTK implementation. The main difference is that while GTK unsets a previous selection the KDE does not. In both cases, selections made previously to the very last one are not used (and, in the case of GTK, are not existing).
I see that having multiple selections can be confusing for users who use the middle button paste. The more user-friendly solution would be to mark the active selection visually: with a different background color, or a thin border around the selected area, or a special sign somewhere in the corner of the selected area. Then there would be no need to unset previous selections (provided, the middle button paste is the only reason to do so).
IMO, the middle button paste should just be removed from everything. The feature is completely unintuitive in more ways than just this, the only times I have ever found it useful is with old and/or broken clients with buggy support for CLIPBOARD.
Hence my confusion with setting multiple selections.