Winit: Clipboard handling?

Created on 19 Apr 2017  路  8Comments  路  Source: rust-windowing/winit

hard normal help wanted api enhancement

Most helpful comment

Since @trimental did some great pathfinding in Alacritty to support this as an external crate, I'd propose closing this issue since @Osspial has mentioned that the tendency is to declare this out of scope.

I think it should be possible to provide this to all winit users without actually having to integrate it directly into winit. That would remove strain from the winit project and I think that since Alacritty is already maintaining a clipboard library, it shouldn't be too much of an issue.

And of course since this would be completely disconnected from Alacritty itself (hopefully), nothing should stop people from contributing to the clipboard library too. The only potential risk I can see is that Alacritty would be 'in control', however hopefully that shouldn't be an issue.

I've also looked into making use of a more standardized crate like clipboard from servo and I think there are a lot of options, but all of them would benefit from a definite decision to mark this either in, or out of scope.

Of course I don't want to monopolize this as something Alacritty will resolve, I'm just offering this as a potential solution. If there are others interested in branching off, it shouldn't keep them from implementing alternatives either.

All 8 comments

I think the clipboard crate works just fine for this, no reason to integrate it into winit, is there?

@torkleyy At least within the x11, there is advantage in integrate the clipboard into winit. This will avoid create redundant window and additional event loops.

Ah I see, thanks!

For the record, on wayland clipboard handling is linked to keyboard focus, and cannot be done from an external crate independently of winit. As such, clipboard support in wayland would require either:

  • to be fully implemented in winit
  • or that winit expose a significant part of its internals (its SCTK inner) in the platform-specific part of the API

After some testing I've found that the clipboard can be accessed from wayland with the current winit methods without any needed change. Its a bit tedious but you can use Display::from_external_display() to access an EventQueue which can be used to create an Environment object; which can be used to make a WlSeat object; which can be used to make a DataDevice object which can access the clipboard.

Since @trimental did some great pathfinding in Alacritty to support this as an external crate, I'd propose closing this issue since @Osspial has mentioned that the tendency is to declare this out of scope.

I think it should be possible to provide this to all winit users without actually having to integrate it directly into winit. That would remove strain from the winit project and I think that since Alacritty is already maintaining a clipboard library, it shouldn't be too much of an issue.

And of course since this would be completely disconnected from Alacritty itself (hopefully), nothing should stop people from contributing to the clipboard library too. The only potential risk I can see is that Alacritty would be 'in control', however hopefully that shouldn't be an issue.

I've also looked into making use of a more standardized crate like clipboard from servo and I think there are a lot of options, but all of them would benefit from a definite decision to mark this either in, or out of scope.

Of course I don't want to monopolize this as something Alacritty will resolve, I'm just offering this as a potential solution. If there are others interested in branching off, it shouldn't keep them from implementing alternatives either.

For everyone interested, an initial version of a potential wayland clipboard solution can be found here (100% of the credit goes to trimental for his great work):
https://github.com/Smithay/wayland-clipboard

Was this page helpful?
0 / 5 - 0 ratings

Related issues

felixrabe picture felixrabe  路  3Comments

felixrabe picture felixrabe  路  4Comments

rukai picture rukai  路  4Comments

k0nserv picture k0nserv  路  3Comments

hobogenized picture hobogenized  路  3Comments