I find it odd that out of all OSes, and DEs, GNOME hasn’t included a clipboard manager with something like history. With even less manageable OSes like macOS having some sort of clipboards.
I am aware you can use extensions but who knows when they decide to stop updating, but many extensions are known to break when a major update happens and many clipboard managers did break at GNOME 50.
This is not an angry or a hate post, but with the technical user-base of GNOME, I want to know the reason for this oversight.
General reason is that clipboard managers were confusing to most people. But there is some effort on having clipboard manager from one of the designers, so who knows, maybe GNOME will grow one. Hard to say for me.
Did GNOME have a clipboard in the past? When was that? I do find KDE’s clipboard confusing at first since their default settings are odd choices but was manageable with the settings.
If GNOME thought it was confusing to the user-base wouldn’t disabling it by default be the better solution? The solutions that exist with extensions are the main problem, many break after updates but that is already a known topic of discussion by many which coincidentally is a problem for this as well.
I think there’s a security risk to keep history of clipboard: when a user uses a password manager, every user’s password are copied to the clipboard.
In this case, if an history of clipboard is kept in memory or in an unencrypted file, all user’s passwords are at risk to be theft. Do you know if other OS and DE clipboard history implementation have a way to mitigate this ?
Not GNOME, per se, but Moblin/MeeGo (which was based on the same tech stack as GNOME) did user testing of a “paste board” in 2010. The paste board was, essentially, what a “clipboard manager” is today: an overview of everything that has been copied inside the clipboard, with the possibility of pasting from a specified item.
The paste board was prominently visible inside the list of available actions, but out of multiple users, only a couple managed to understand it, and only one—a student—made use of it. When it came to holistically decide what to de-prioritise in the design and implementation of newer versions, the paste board was an easy picking.
The equivalent of functionality that is off by default, and does not incur in a cost for the GNOME project, is an application or a shell extension that you need to install yourself. Of course, that has another cost, but as the say: no such thing as a free lunch.
I really liked hearing those very specific and niche details. Even with your last point, I still think it should be included. GNOME, which positions itself as future-forward, should have that by now.
Interesting topic for me, coming to Linux after over 4 decades GUI use on Apple products.
Clipboard managers have been around a long time on Mac, recently in the OS itself, otherwise through 3rd party apps such as LaunchBar (macOS only). I have come to find a clipboard history usage quite handy in daily computing. I agree such software should address security.
As I set up my new laptop with Ubuntu 26.04 and Gnome 50, I have been looking for features I have had on Mac for a long time and recently found one that I’m trying out. A quick search for ‘linux clipboard manager’ generates lots of results, including some that address security concerns in various ways.
For instance, in KeePassXC, one can copy username/password etc into the clipboard and automatically clear it after a set time, but it remains in, and is usable from, the clipboard history of LaunchBar. So things can get tricky like that quickly.
Whether such a feature belongs in GNOME or the distro or left to independents, I am really too new to the Linux world to know. Like a lot of software, it might be useful to let independents develop various ideas, and after a while when the developers-in-charge at GNOME, Canonical et al see what is turning out to be most popular/addresses most important features, then bring those features and the developer into the product/team.
Not that I have any say in here, I’m not even a contributor, but I’d ask the question why that is future-forward. It increases complexity in interaction to the point of likely going unused while introducing potential new security vulnerabilities, thus costing time and effort in an ongoing basis as well as introducing a risk. In the long run, one would need to justify paying that cost/expending that effort and it would need to provide an appropriate payoff. I struggle to see that here.
I don’t think a clipboard would be hard to maintain, and I especially don’t think that tool is future-forward. I only used the term future-forward in an attempt to be polite and describe GNOME itself, and how GNOME forces many defaults or changes with little user control, in the name of simplicity or optimization.
Complexity, sure, security issues, sure. I doubted the usefulness of clipboard management when I first heard about it, but after some time using it, I find it quite useful and am happy there are ways to add it to Linux. Whether useful or not I suppose depends on how the user works.
I"m also not a developer or contributor, just a new user. Would be interested to learn how such things are worked out in the Linux world. That is, a new idea comes up, but does it belong in the Kernel or GUI or other component in the case of clipboard manager? Do the ideas bounce around in the world of Extensions and so on until they get popular enough for the consideration by the GNOME team?
You don’t “request” features or changes, per se. GNOME is not a company, and there’s no such thing as a “GNOME team”: you have multiple projects, multiple maintainers, and various teams.
Since you’re asking for something that should be provided by GNOME Shell, you’ll have to present your case to:
the GNOME Design team
the GNOME Shell maintainers
You’ll have to argue your case with some data on your hands, rather than your personal belief—and, more importantly, you should never argue that something “will be better for every user”, because that’s very, very seldom the truth. The data you can bring is:
prior art
a set of potential use cases, and how they interact with existing behaviour
some user testing, which can be done by simply installing one of the clipboard management extensions, and then recording the impressions of users (that are not you) placed in front of them
This is pretty much what the GNOME Design team does for every feature.
If the Design team signs off this change, then you can move on to its implementation; at this point you iterate over the implementation and the design, because no design survives contact with the users intact. After a few iterations, and assuming it can be made to work, the Shell maintainers will review the code and merge the functionality.
If you don’t know how to write code, my suggestion is to start from an existing clipboard manager and figuring out how it works; or you can convince somebody to work on it for you. Do not use LLMs or genAI to generate code you don’t understand, unless you plan to just use the code locally.
I need to update my comments… I was happy with a clipboard history extension until today. I was just doing normal ordinary things like web browsing, email, chatting and clicked on the menu bar icon for the extension and the OS stopped responding, went black, and returned to the login window. Not sure what that’s called in Ubuntu/GNOME.
Signed in, waited a bit and clicked it again and same thing happened. So the extension seems to be interrupting the OS after not being used for some time. Alas.
Thanks @jbenzler , an interesting discussion there. Alas under Relevant Art for macOS is only the OS itself’s clipboard history function listed. There are quite a few more which would provide many good ideas.
The only one I’ve used for several years now is a component of the multi-functional LaunchBar app. I can’t recall now the names of others but there are several dating back many years. The developer of LaunchBar is presently working on LittleSnitch for Linux so might might be reachable for insight/ideas etc.
, but please avoid ‘me too’ and similar comments).