Implement getting X11 clipboard contents #1805
Conversation
psychon
force-pushed
the
x11-clipboard
branch
2 times, most recently
from
324577f to
bfad91d
Compare
|
I forgot to mention in any of the commits: This is a first step towards #937. (Now that I left this here, GH will surely link the issue to this PR) |
|
Oh and: Somewhen, this might need timeouts. If the transfer did not finish after [time], abort and return None. However, now is not the time for that. (As in, I don't have the time right now.) |
|
I updated this to also implemented
I tested this with: fn main() {
let app = druid_shell::Application::new().unwrap();
println!("{:?}", app.clipboard().available_type_names());
println!("{:?}", app.clipboard().preferred_format(&["FOOBAR", "UTF8_STRING"]));
}Output is: With the gtk backend I get: Dunno why the gtk backend also includes the number of the atom. That does not seem useful to me and would break my implementation of |
psychon
force-pushed
the
x11-clipboard
branch
2 times, most recently
from
1c8b3c0 to
6e09b50
Compare
|
Taking a look at this, and just wanted to make sure that the changes related to the screen number and timestamps is intended to be part of this PR? |
|
timestamp is needed for the clipboard, screen_num looks like a unrelated refactor |
|
To clean up this PR, I rebased it on current Edit:
It is indeed unrelated. If you want, I can remove it from this PR. |
This commit implements X11 clipboard transfers as specified in ICCCM.
This allows to get the contents of the clipboard.
X11/ICCM call the underlying mechanism "selections". This works with
ConvertSelection requests. The X11 server forwards these requests to the
selection owner which then uses SendEvent requests to answer. Thus, this
requires some way to blockingly wait for events. For this purpose, a
FIFO queue (VecDeque) of pending events is introduced. When waiting for
the "right" event, "wrong" events are pushed to this queue for later
processing.
Doing selection transfers requires an up-to-date-ish X11 timestamp.
Thus, the Application now tracks a timestamp and updates it whenever it
gets a newer timestamp.
As an unrelated refactor, this changes the X11 screen number to be saved
as usize instead of i32. This saves a couple of unnecessary casts. I
didn't want to do this too much in this commit, so screen_num() still
returns i32 instead of usize, even though I think it should be an usize.
Besides the above, the actual selection transfer is fully contained in
clipboard.rs.
The basic steps for getting the selection contents are:
- create an invisible window (used for the reply)
- send a ConvertSelection request with this window
- wait for a SelectionNotify event (at this point, the selection owner
set a property on the window)
- get the contents of the property from the window
- in case the selection contents are larger than allowed for window
properties, the property as type INCR. This indicates an "incremental
transfer" which works as follows:
- every time the property is deleted, the selection owner creates a
new property with the next chunk of the property
- thus, we have to wait for PropertyNotify events for our special
window and react to them by getting the next piece of data
Signed-off-by: Uli Schlachter <[email protected]>
|
@psychon if that's the only unrelated change then no worries, but if there's other stuff in here that's unrelated breaking them out into a separate PR will definitely make review easier. |
@maan2003 turn `for` into functional! Co-authored-by: Manmeet Maan <[email protected]>
Signed-off-by: Uli Schlachter <[email protected]>
Signed-off-by: Uli Schlachter <[email protected]>
This PR adds support for getting the clipboard contents. I only tested this with strings, but would expect that other kinds of data should work as well. There is still lots of TODO left here: Only
get_stringandget_formatare implemented. Of course all theput_*are missing, but alsoavailable_type_namesandpreferred_formatare missing since I ran out of time for now.Edit: Updated to also implement
available_type_namesandpreferred_format.put_*is best left for another PR, I think, because that requires keeping some state and my best idea for that so far is to changeClipboardintoRc<ClipboardState>so that the clipboard contents can be kept inClipboardState.