-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write support; dependencies #2
Comments
Hey!
IIRC,
I believe these could be fixed and contributed back, but I think it's best to have a good amount of control for fast-prototyping as we figure things out.
More or less the same reasoning. I'd like to get rid of most of the dependencies of
Basically, I believe there is a lot of coordination that needs to happen for a viable library like this to exist. The plan is to experiment here and contribute back if possible.
That'd be great. Writing the clipboard in X11 is quite involved, as we need to run some kind of server that responds to paste requests from other windows. May be interesting to consider using futures... We should also figure out eventually how to deal with copy/pasting other kinds of data (like images, files, etc.) and how to unify all the platforms behind a single, nice API. |
Starting to regret this... X11 clipboard functionality is unintuitive and badly documented. First point, I guess, is scope and platform differences:
All platforms appear to support multiple formats for reads and writes:
Perhaps the best approach is to provide an enum of common types and an API for usage of an arbitrary MIME type. This implies that data transfer uses only byte-arrays and higher-level functions for Clipboard reads via futures: as far as I understand, this would only be applicable to Linux platforms, and it's only real purpose is to hide the lag between request and receiving clipboard contents if the application can do other work in the mean time. I haven't much experience with async models, but the extra complexity for little-used functionality doesn't sound attractive: I don't expect many apps will be able to put it to much use (e.g. an input field must complete a paste action before processing other input anyway). (There is also another approach to hiding this lag: pro-actively copy clipboard content whenever updated, at least for text. On Wayland this only happens with keyboard focus and we could apply the same limit on X11, so it's not as much overhead as it first sounds. But maybe your current 3-second timeout isn't such a bad option.) |
More about async: Android's URIs are a form of indirect data access, though it sounds like they are broken in practice, so it may only be interesting to support sub-sets such as URLs. This is basically text anyway. Window's SetClipboardData supports usage with a null data parameter, implying a requirement for communication with the providing app. Maybe it's useful to use an async API for non-text data, but not for the higher-level read/write |
Seems to me that this has no effect on dependencies? Anyway, xfixes was only used for the |
FYI, |
Hey, I started looking into adding write support (still only for strings). But this immediately brought up some questions about dependencies:
If you have no objections I might start by ripping out those.
Also, I was going to go with
fn write(&self, string: std::borrow::Cow<str>) -> Result<(), Box<dyn Error>>
, though given thatclipboard-win
is the only backend not requiring an allocated string anyway, I'm less sure if it's worth it.The text was updated successfully, but these errors were encountered: