GitLab

My thought is - let's call whatever the orbital modifier key is "super", although it could be ctrl or alt or anything chosen by the user

Here is the potential new event

enum ClipboardEventKind {
  Copy,
  Cut,
  Paste
}

struct ClipboardEvent {
   kind: ClipboardEventKind,
   size: usize,
}

The reason to have all of them going through the same event, is there may be shared operations like opening a clipboard file that would be optimal to do in one match brace on the Event. The size field is to provide the size of the clipboard and may not be used for Copy or Cut

• super+c would send a new event - ClipboardEvent(Copy) - to the window that is focused
• super+x would send ClipboardEvent(Cut) where the application just deletes what it has selected
• orbital would also clear the currently selected clipboard buffer before sending the event, for compatibility with applications that do not have selection support
• if that window has something selected, it would dup(window_fd, b"clipboard"), write(clipboard_fd, &clipboard_data), close(clipboard_fd)
• alternatively, it could write(window_fd, format!("C:{}", clipboard_contents)) - but is allocation worse or an extra syscall?
• in the dup case, the clipboard could be opened alongside the window at all times to save a syscall

Pasting would involve using the size field to determine how to handle the clipboard contents. I am unsure if the clipboard fd will support seek or fstat - that would provide an alternative way to peek at the size and to do partial reads

• super+v would send a ClipboardEvent(Paste)
• the window would dup(window_fd, b"clipboard"), read(clipboard_fd, &mut clipboard_data), close(clipboard_fd)
• I am not aware of a good alternative, read(window_fd) should usually return events. Doing anything else would break backwards compatibility
• Again, the clipboard could always be open in order to save a syscall