I just realized that the promise of ipv6 will create a demand for good clipboard integration in console applications! Imagine the very long ipv6 addresses that many Unix/Linux admins will have to move from spreadsheets into configuration text files!
Therefore I propose that we start thinking about a libclipboard library. As a pragmatic bridging solution we could easily make a small DBus service that not converts but bridges the target requests to the x11 clipboard owner. This service would just play as a proxy rather than something that collects and harvests x11 clipboard targets (the x11 clipboard supports requesting the owner to convert to a desired format, getting a list of available formats, etc – called targets -).
Meanwhile we could let console applications finally enjoy a decent clipboard that can actually make it possible for a console application to request multiple formats. Sounds better than xterm hacks to me.
Before continuing with reading, do this in your mind:
If you are a religious vim user:
export EDITOR=vim
If you are a religious Emacs user:
export EDITOR="killall -9 vim; emacs"
Examples:
- Select text in Firefox, paste as HTML source in $EDITOR
- Select two columns and twenty rows in a spreadsheet application, and paste as a comma separated list in $EDITOR
Maybe even have an easy to configure filter application that on-the-fly converts just a copy source into a format that the admin wants in his configuration text file. You know how management always delivers things like IP addresses in spreadsheet format (it’s just a silly example, really).
We could also let such a library solve the problem of two applications running on the same computer being displayed on a remote X11 server having to transfer large clipboards over the X11 protocol (over the wire).
I still think PRIMARY and SECONDARY are broken concepts by design. But I also agree that this is subjective (but really, let’s be honest about it, it’s broken. Seriously).
Of course I realize that whether or not I’m right about such a solution only depends on somebody (like me) doing it rather than just blogging about it. I have always been tempted to try to start something. Who knows someday I will?
If you’re going to do this, please consider basing it on the concept of a kill ring instead of just a single-entry clipboard. Yes, this means more changes to applications, but it would be a great stride in usability and a place where we would be *ahead* of the Windows/OSX universe instead of mimicing them.
I’m not sure now… Was this blog entry meant sarcastic or was it for real? Sorry, the title suggests a sarcastic remark about how people whine about the clipboard in X and want it to work “like in Windows”, and the “Select text in Firefox, paste as HTML source in $EDITOR” thing seems over-the-top ridicule; but the entry gets more serious then…
So, for clarification: is this meant seriously or not?
Like the Cola Zero advertising, oliver: Both
No.
just do it!
and call it something like “ClipboardKit”, as these are the names that go with new implementations nowadays… (…)
@thp: heh :)
(Don’t wait for it. If I start something like this, it would take ages before it would be usable. It would also probably take ages before I start something, too)
A plausible first step would be adding a command-line option to xsel to list available targets and select a target. Hint, hint. ;-)
Then you could extract xsel’s code into a libclipboard.
OK, if you are going to make changes to console apps, how about this:
1) Make a mechanism for any asynchronous notification of a console application of events (DBus already fills most of this role).
2) Allow other apps to connect to this mechanism. Ideally, it should work “like a socket” in that multiple apps can be connected at one time, and the target app can differentiate between the connections. (Note: This could be something as simple as a unique integer per connection – you don’t necessarily need a full socket like bind/listen/accept mechanism.)
3) Allow the applications to have a means to have a “conversation” about the object(s) being moved.
Example:
Yo, editor: I have something for you – what can you accept?
I can take XML, HTML, CSV, text.
OK, here comes XML (send).
4) Make this truly an OO system: applications can define object types and interfaces.
So, now you can do something much like the underlying ideas of Microsoft’s Monad. I could, for example, select a set of files in Nautilus and drag them to a command line, where they would be represented by a single object (which would be a list of objects that represent the files), then I could select some text and drag it (again, an object), and so on.
You could also use that to build an OO pipe mechanism: given a command line like
foo | bar | baz | narf
on startup, foo could establish an object connection with bar, bar with baz, baz with narf, and thus pass things other than generic text (imagine if, for example, cpp could pass an object representing the preprocessed file(s) rather than just a text stream, making multiple file compiles a bit easier). Also, unlike a Unix command line pipe, the communications could be two-way: bar could pass objects back to foo if needed.
Use *that* for your clipboard mechanism as well, and I think you could have something.
The original X11 selection mechanism was simple and easy to understand. The cut-and-paste mechanism that Apple foist upon the world is pretty obscure: you can’t see what you’re pasting, and it’s unclear what happens to the selection when the source application exits. The problem with X11 is that more and more people brought Mac-style cut-and-paste to X11 and now X11 is stuck with both mechanisms.
All the other ills you describe are problems in applications. If applications don’t support transferring images, then images don’t work. If applications don’t indirect large data transfers through local resources, then they will get transferred through the server.
We don’t really so much need a “new” clipboard library, we need a library that makes it easier to do the right thing with the current clipboard facilities, so that people will, in fact, cope with images and large transfers.