Skip to content
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

Handle X11 selection for stopped clients #821

Closed
blueyed opened this issue Oct 21, 2017 · 8 comments
Closed

Handle X11 selection for stopped clients #821

blueyed opened this issue Oct 21, 2017 · 8 comments

Comments

@blueyed
Copy link

blueyed commented Oct 21, 2017

If you stop an application where something is selected (using the mouse typically), e.g. a terminal (using the PID from echo $PPID) with kill -STOP $pid, trying to paste this selection somewhere else will block, until you kill -CONT the application with the selection.

Could CopyQ handle this case?

This is related to awesomeWM/awesome-www#111, where I dynamically stop e.g. browsers when they are not focused.

I've tried using xsel --keep --primary before the kill -STOP to work around this, but it appears to cause issues with Neovim, which uses xsel itself for clipboard management.

@hluk
Copy link
Owner

hluk commented Oct 21, 2017

You could copy the selection again in CopyQ before stopping the other application. This way, CopyQ will provide the selection text instead of the other app.

copyq 'copySelection(selection())'

@blueyed
Copy link
Author

blueyed commented Oct 22, 2017

Thanks, that seems to work well.

Could this be done automatically - e.g. similar to how it is done with killed clients?
Or is CopyQ using X11 events that only happen when a client is killed, but not when it is only stopped?

@hluk
Copy link
Owner

hluk commented Oct 22, 2017

Could this be done automatically

I don't know how. This is really strange use case - AFAIK, GUI apps are usually not stopped.

CopyQ could automatically take ownership of the X11 selection just after it changes, but some apps deselect text when this happens.

@blueyed
Copy link
Author

blueyed commented Oct 22, 2017

OK.
Thanks for your support.

@blueyed blueyed closed this as completed Oct 22, 2017
@blueyed
Copy link
Author

blueyed commented Oct 22, 2017

@hluk
Is it possible to know who owns the selection? (e.g. PID)
I would then only call this in case it is owned by the process to be stopped - otherwise e.g. urxvt unhighlights its selection (like you mentioned before).

@hluk
Copy link
Owner

hluk commented Oct 23, 2017

Is it possible to know who owns the selection?

I have no idea how to do that (perhaps using XGetSelectionOwner and somehow getting PID for the window).

@blueyed
Copy link
Author

blueyed commented Oct 27, 2017

Yes, that's what I've found, too.
Then XGetWindowProperty could be used, but the code from https://lists.freedesktop.org/archives/xorg/2005-April/007254.html gave me "No properties".. :/

Could you imagine having an API for this in CopyQ, to get the PID of the clipboard or selection owner?

To simplify things for my usecase it would be great to have something along "take ownership of selection/clipboard for $PID".

@blueyed
Copy link
Author

blueyed commented Oct 27, 2017

I think a good workaround is also this:

xclip -o -selection clipboard | xclip -verbose -selection clipboard &;
xclip -o -selection primary | xclip -verbose -selection primary &;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants