There is already a switch for this in gnome-tweaks so I don’t see what all the fuzz is about. AFAICT it’s only a default setting that is changed. The switch could possibly be moved to the main control-center if people have a problem with Tweaks? If GTK5 and the rest of the Linux desktop would completely remove this feature it would of course be more serious. I don’t think Wayland supports primary clipboard by default as it still requires an extension.
1 Like
There is not even a real data or reason to change the default.
2 Likes
If GTK5 and the rest of the Linux desktop would completely remove this feature
Yeah, I’m sure maintainers of every GUI app and toolkit ever written that’s not GTK+ – yes that includes all applications ever written that use Java Swing, AWT, Tk, Python Tkinter, FLTK, FOX, Xforms, and even unmaintained toolkits such as Xaw, XView, GNUstep and OpenMotif – will immediately make it a priority to write adapters that check on startup for gtk-enable-primary-paste and override their existing defaults accordingly, just because lazy GNOME team changed a single line in the configuration.
On top of it, obviously lacking the technical expertise to make their idea work as a user would expect, they arrogantly shrugged and said they expect everyone else to write code and adjust their apps. To quote Emmanuele Bassi, representing the GNOME team on this thread:
I suspect the change in default might even lead to applications being changed to conform.
Yeah I’ll be on the lookout for that to happen. I’m sure it’s any day now.
That was obviously sarcastic, but in all seriousness, I’ll refrain from even using GNOME, from recommending it to anyone, and certainly from contributing any code to it. Not because of this feature, but because their team just demonstrated a lack of both engineering skills and social skills.
2 Likes
Please calm down. Nobody is doing anything to annoy anyone.
Btw, there is no “GNOME Team” and I hate this badge. There were several code contributors who chimed in here and you being needlessly combatative isnt exactly inviting to further discussions.
GNOME is made out of hundreds of contributors.
Because we’re not at your beck and call.
And considering your constant aggressive and sarcastic tone, I don’t think anybody working on GNOME wants to have anything to do with you, either.
So:
Feel free to see yourself out.
2 Likes
Okay, we’ve had far too many people coming here from known hostile places, insulting volunteers, and not even bothering to read the actual issue.
tl;dr: There are no plans to remove support for the primary selection buffer in GNOME.
- GTK still provides API for retrieving the primary selection buffer
- GTK still provides a setting for enabling and disabling it in the widgets that it provides to application developers
- application and library developers using GTK are still supposed to look at that setting when implementing their own custom widgets, if they wish to do so at all
- GNOME Shell implements the primary selection protocol, and GTK consumes it if it’s available, while providing a non-shared fallback that only works within the same application
The setting’s default has been toggled from “enabled by default” to “disabled by default”, after nearly 15 years of on again/off again discussions. The setting only applies to GTK applications, and to whatever application monitors the GNOME setting—which is currently proxied to Flatpak applications only by the GNOME desktop portal. This means that if you are not running a GTK application under GNOME, the default “middle click to paste” behaviour will still be enabled just like it is today.
Changing the default is, ideally, just the first step towards improving the behaviour of GTK with regards to text areas, while removing a well-known trap for newcomers and experienced users alike, especially in a world where a “middle click” is often emulated and does not behave consistently across different platforms and application stacks. Since nothing specifies the behaviour of this feature, and it’s all left to whoever wants to implement it to define what it does and when, consistency is already out of the window.
The problem with people taking their information from known slop “news” websites is that they lack critical information until the GNOME project makes an announcement; since everything we do is public, we cannot coordinate announcements before any change gets “leaked”, leading to an avalanche of folks foaming at the mouth. The alternative—making everything secret until a press release is published—runs counter to everything the GNOME project does. Even if there had been an entire plan on the replacement of middle-click to paste, we’d have seen the same behaviours because the point brought forwards by the people shouting the loudest has been pretty clear: they don’t want this to change at all, and there is no middle ground to achieve, or actual feedback to listen to.
As a personal note, I am appalled by the behaviour of so called “journalists” and “power users” that behave like GNOME’s development is meant only for them, and that everyone contributing to GNOME is fundamentally a slave to their personal opinions on what an OS should look like or behave in 2026—all the while contributing precisely nothing to the GNOME project, except for their entitlement. While I wouldn’t want other projects to suffer those people, either, I want to remind folks that GNOME is not the only desktop environment in existence.
I am going to close this topic, because letting it fester just to let people vent isn’t conducive of a good community. If people decide to open new topics because they are still at the “anger” phase, or try to negotiate because they reached the “bargaining” phase, I will start timing them out.
6 Likes