For instance, in this mode you hit Ctrl+C five times, then the subsequent five Ctrl+V actions paste the data in FIFO order. It may not seem like much, but going in between app windows in order to grab data is a big time sink. Being able to copy items sequentially and then paste them sequentially would be a killer app in most Excel heavy office workflows. You could also add a toggle for LIFO, or maybe some keyboard shortcut / chording for toggling modes while the user is pasting.
I had actually tried to implement this as a hobby project but truthfully, my MVP was rudimentary at best because I’m inexperienced at COM+ and developing for the Windows Shell.
Edit: I’m using ‘Stack/Queue’ loosely, not in the rigid data structure term of art way.
Would this work, or is there more to it?
While there definitely are good use cases where rich text clipboard should be supported, for me personally a major use case requires eliminating rich text - where I'm frequently pasting some data from some web system into e.g. a word document and I want to explicitly paste just the text, because it really does not matter what styling the web page used for some ID. Word's "Paste Special"->"Unformatted text" is horribly inconvenient, so currently I just paste it in my text editor and re-copy it, ensuring that only the text remains in the clipboard.
Edit: I see Microsoft Word doesn't natively have that shortcut, but there are two ways to "implement" it here: https://superuser.com/questions/988527/how-can-i-use-ctrl-sh...
Removing rich text formats is a good idea for a clipboard manager feature/plugin, though.
I used to use PureText for this, but this morning I discovered CopyQ and now I'm enjoying its enhanced clipboard capabilities, including that feature.
If I want to move things between them, I should open the clipboard manager and manually move an individual item, or bridge the two clipboards for a specified time, after which they go back to being isolated.
Is that sensible/practical?
All of my AutoHotKey triggers are off of the right control since I noticed a long time ago that I never use it regularly. In the old days (~2004) I would use it to write HTML. Hitting right Control+a for example would surround the text with an <a> and have logic for @ or http: etc - or hitting right Control+l would surround a list of items with <ol><li>. These days I have very few macros, the most useful one being code that will "type" what's on my clipboard rather than paste it which is useful for places that don't allow pasting.
>^v:: SendRaw %clipboard% Return
When an application makes data available in the clipboard, it's a free-for-all for every other application. The clipboard manager would have to race other applications to make a copy of the data, and then empty the OS clipboard.
APIs also may not allow making decisions based on which application requested the clipboard. It's possible to do in X11, but not Windows.
This goal could be achievable by intercepting the OS clipboard API. On X11, this can be done by MITM-ing the connection to the X server - https://github.com/CyberShadow/hax11 does this, and already has one clipboard-related security feature (disabling the selection mechanism). On Windows, the best bet is probably global DLL injection and API hooks, but applications can "opt out" by running as a different user or requesting a higher integrity level.
In addition to: cut | copy | paste
Add: swap
It swaps the current selection with the contents of the clipboard (replacing the clipboard with the selection, replacing the section with the prior contents of the clipboard — a swap).
It's a nerdy ask, if anything adds more complexity to the clipboard concept. But I have found myself having a need for this shortcut often.
Maybe others have as well.
- The system should be able to efficiently store, manipulate, and search an unlimited number of clipboard entries with reasonable performance.
- All functionality should continue to be available when offline (other than sync).
- The software should be cross-platform, and should have implementations for major desktop platforms (Windows, X11, Wayland, macOS).
- It should be safe and easy to simply copy the database file to another host, "pre-seeding" the clipboard history.
- It should be easy to write interoperable implementations of bridges/clients in most programming languages.
- Non-GUI functionality should be separated (or separatable) from GUI functionality, so that a GUI toolkit doesn't need to be loaded at all times.
But I'm not sure how to do this in SQLite as it probably does not fill deleted records with zero bits (but you could do that in your application):
- Deleted clips must not be trivially recoverable.
To make SQLite zero-out deleted pages, issue "PRAGMA secure_delete = on".
The clipboard manager I used on Windows, which only works there and hasn't been supported for a while, allowed a "Win+V, type, enter" workflow to very easily search for whatever I "type"d as a substring, and paste that entry. No interacting with menus, no up/down presses, no mouse. I miss that feature.
If I would guess, I would assume there is already one somewhere.
If there isn't maybe just using Syncthing would be enough?
Nobody needs yet another clipboard manager as there is almost a perfect one out there. Which can be extended by plugins! (I don't think it's a valid approach to start a new project because some project doing most of the wanted stuff isn't "perfect". The result is almost always "yet another 80% solution").
The "limited" number of entries is not an issue, imho. You can set it to x-thousand entries if you like. (One thousand entries are enough for more than two weeks of history for me. A clipboard is not a means of permanent data storage at all so this is fine; even one can have something akin to permanent entries by just using tabs in CopyQ).
Implementing in CopyQ some of the suggestions mentioned here would be great though!
You can read the issue I filed in CopyQ's repository back when I switched to Linux and had to stop using Ditto for the justifications of infinite history: https://github.com/hluk/CopyQ/issues/510
CopyQ is also bound to use Qt's clipboard implementation, which provides the common subset of Qt's supported platforms, with all the consequent limitations. See the other issues I filed for details.
Ability for keyboard-free editing, as in classical X: select to copy, click to paste.
- The system should be able to efficiently store, manipulate, and search an unlimited number of clipboard entries with reasonable performance.
- The software should be cross-platform, and should have implementations for major desktop platforms (Windows, X11, Wayland, macOS).
- Non-text data (images) and rich text (e.g. HTML) should be supported.
- Clipboard history can be shared across instances using a network connection.
- Instances may temporarily go offline, and sync up with other instances once a connection is re-established.
- - All functionality should continue to be available when offline (other than sync).
- Deletions must be propagated across instances.
- Deleted clips must not be trivially recoverable.
- Deleted clips must be deleted everywhere, including any copies in OS clipboards.
- Sync should be incremental (and otherwise generally efficient).
- When connected, actions should propagate across instances in real time (instantly, as opposed to polling, and with no unnecessary roundtrips).
- Relaying should be supported (in a `A <-> B <-> C` scheme, A should be able to see C's actions).
- Network topology cycles should not result in a feedback loop.
- It should be safe and easy to simply copy the database file to another host, "pre-seeding" the clipboard history.
- Support "portable installs" (carrying the software, configuration, and database on portable storage).
- It should be easy to write interoperable implementations of bridges/clients in most programming languages.
- Non-GUI functionality should be separated (or separatable) from GUI functionality, so that a GUI toolkit doesn't need to be loaded at all times.
Any suggestions?