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

Multi-DISPLAY support #22

Open
blueyed opened this issue Mar 16, 2016 · 6 comments
Open

Multi-DISPLAY support #22

blueyed opened this issue Mar 16, 2016 · 6 comments

Comments

@blueyed
Copy link

blueyed commented Mar 16, 2016

I am using different X server instances, and have noticed that you can only have one clipster daemon running, and it's bound to that $DISPLAY.

I might be nice to have headless daemon that can be used from different environments, and where clipster -s (to open the selection window) uses the current $DISPLAY.

@mrichar1
Copy link
Owner

Just to check - are you referring to being able to run a separate clipster daemon for each X session, or running one daemon and maintaining a shared clipboard history for them all?

The former is easy to achieve by just creating a separate config and data directories for each session, and using --config to point different clipster instances to different config files, and setting $DISPLAY when the daemon is started.

The latter is probably also achievable by watching the clipboards of multiple displays.

Currently we do the following to open the default primary selection:

self.primary = Gtk.Clipboard.get(Gdk.SELECTION_PRIMARY)

This could be changed to accept a display name, something like:

self.primary = []
for display_name in (":0", ":1"):
    display = Gdk.Display.open(display_name)
    self.primary.append(Gtk.Clipboard.get_for_display(display, Gdk.SELECTION_PRIMARY))

It's then just a matter of handling the owner-change events for all the selections in the the list, rather than just one

The one issue is that I've not managed to find a way to list all the active displays on a system, so you would need to pass in the list of displays to be 'watched' as a config option at startup. This might be the best option anyway, since you may have 3 displays running, but only want to share the clipboard between 2 of them.

This is probably a useful feature, so I'll look into adding it to the code in the near future.

@blueyed
Copy link
Author

blueyed commented Mar 17, 2016

Awesome, thanks!

I can see the use case for both approaches, and it's good that the first one already works by using separate configs. Do you think it's useful to be able to specify only the data_dir through a command line argument? (~/.local/share/clipster/another_session)
This way you would not have to create separate config files.

@mrichar1
Copy link
Owner

Just realised I never answered the final part of your question - apologies!

clipster uses the following mechanism to decide on the root to use for creating the clipster/ data_dir:

xdg_data_home = os.environ.get('XDG_DATA_HOME', os.path.join(os.environ.get('HOME'), ".local/share"))

So if you want to run different instances of clipster with the same config, but different data_dirs, then do:

XDG_DATA_HOME=/tmp/foo clipster -d

This should create the directory /tmp/foo/clipster containing subsequent history, clipster_sock and clipster.pid files.

(Equally, XDG_CONFIG_HOME can be used to use multiple clipster.ini config files).

@mrichar1
Copy link
Owner

As to the idea of a single clipster instance being shared between multiple X displays - I'm going to leave that one open but as a low priority - if there are more people requesting this, or if someone submits a PR for it, I'm happy to revisit this.

@blueyed
Copy link
Author

blueyed commented Jan 18, 2017

Thanks!
Makes sense.
For now I am using CopyQ.

@stale
Copy link

stale bot commented Apr 16, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Apr 16, 2022
@stale stale bot closed this as completed Apr 28, 2022
@mrichar1 mrichar1 reopened this Apr 28, 2022
@stale stale bot removed the stale label Apr 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants