Posted Thu, 15 May 2008
I suspect making a generic tool to do this would be difficult. keynav and xdotool aim to solve some of these problems, but what about some of the more complex ones? Is it worth trying to solve these edge cases with automation? Specifically, I mean solutions where programatically you'd be talking to two or more separate systems (or APIs).
One specific set of problems is because X11's default clipboard buffer is not the same thing as GTK's clipboard buffer. So, in firefox, using 'middle click' to paste gives me X11's clipboard while CTRL+V gives me GTK (firefox)'s clipboard contents. It's likely I'm calling this thing "X11's clipboard" when it's really the "X11 Selection". It seems simple to write a tool that would copy X11's current selection to GTK's clipboard.
You could have code that looked like this, but it wouldn't be efficient:
while true: if gtk_clipboard_changed: set_x11_clipboard(value) else if x11_clipboard_changed: set_gtk_clipboard(value)You could make that not chew up cpu by adding a small sleep at the end of each iteration, but that still sucks. From what I can tell, GTK has a way to block for clipboard changes, but X11 may not.
If the X11 application uses cut buffers, then the root X window gets notifications about cut buffer changes. However, copying stuff in firefox doesn't show any cut buffers being used.
Alternately, we could hack our own "ctrl+v" functionaly by grabbing that keystroke, or by grabbing a different, unrelated keystroke, which would do:
- copy primary selection to clipboard
- send literal "ctrl+v"
- restore clipboard