Open stevengj opened 11 years ago
See also the discussion in JuliaStats/DataFrames.jl#359
I believe the way most clipboard systems work is that they register themselves with the clipboard subsystem when they copy something to the clipboard and then when a program wants to paste, a negotiation of what format to use takes place. So that's actually an asynchronous background task. Fortunately, Julia's I/O system is already well designed for this sort of thing. It would be really slick, for example, if we could seamlessly to copy-and-paste interaction with, say, Excel – if you paste a DataFrame into Excel, it should Just Work™. I'm not certain if pasting data from Excel into Julia should produce a DataFrame (when that package is loaded, of course), but that certainly would be slick.
A while ago, I started working on XClipboard.jl. At this point, it is a reasonable replacement for the clipboard()
function in Julia: it works directly with Xlib (so doesn't require xclip or xsel to be installed), and can at least receive the data from anything on the clipboard (though decoding anything besides text is still iffy).
I based it off of a BSD licensed example program that is reasonably complete (here: https://github.com/edrosten/x_clipboard). Going the other direction (placing things on the clipboard) shouldn't be too much harder, although I have no plans to work on it any time soon.
The main downside is that this is X11 only, so it won't be useful for Windows/Mac users. Oh, well.
Cheers, Kevin
I believe the best way forward for generic clipboard support is to expose the GtkClipboard object: https://developer.gnome.org/gtk3/stable/gtk3-Clipboards.html
this would already handle image and text format conversion, and unifying cross-platform API differences
currently this object is not exposed simply because I haven't had the time to consider how to best integrate it into the Julia writemime model
I'm skeptical that we should introduce a dependency on Gtk just for rich clipboard support...
When I was working on XClipboard, I looked around for a cross platform clipboard manager, and pretty much came up empty. Gtk and Qt were the closest, and I shied away from both. There doesn't seem to be any standard library for this.
@stevengj not in base, but loaded on request (i'm planning on experimenting with working on making Gtk.jl load much faster than it does now so that it is reasonable to add a dependency without incurring much of a load-time delay)
@kmsquire i suspect it just makes more sense to talk about a clipboard in the context of interactive toolkit, so they are typically coupled. for example, Gtk makes use of it's text widgets to provide rich text conversion support, and it's image processing framework to do image format conversion on-request.
clipboard(x)
was recently added to put a text representation ofx
onto the OS clipboard. Since essentially all modern operating systems support multimedia clipboards, shouldn't we have some kind ofclipboard(mime, x)
function that callswritemime(io, mime, x)
to storex
as an arbitrary MIME type on the clipboard? Note also that OS clipboards typically allow one to store multiple representations of the same object, so maybe it should beclipboard(x, mimes...)
.(There's also the question of whether
clipboard(x)
should default totext/plain
or if it should write additional MIME types.)cc: @StefanKarpinski