xcmenu - lightweight clipboard manager for X (formerly loliclip)

Alien282 · 2013-07-31 16:56:14

I was asking more about the WAY they do it - because, e.g. parcellite, also does synchronization between clipboards (primary and clipboard) and I was asking whether they "poll" too - i.e. do they have such a "delay" that I am experiencing?

Anyway, mostly now it works fine, however I see an issue now that I can't copy from Pidgin chat windows while loliclip is running. Any idea why that might be?

Cloudef · 2013-07-31 17:16:30

I was asking more about the WAY they do it - because, e.g. parcellite, also does synchronization between clipboards (primary and clipboard) and I was asking whether they "poll" too - i.e. do they have such a "delay" that I am experiencing?

Parcellite for example polls too yes. However, you won't experience the issue since it won't actually steal the ownership from other X11 client.

Anyway, mostly now it works fine, however I see an issue now that I can't copy from Pidgin chat windows while loliclip is running. Any idea why that might be?

What changes did you do? Output of loliclip (compiled without -DNDEBUG switch) can be helpful as well.

Alien282 · 2013-07-31 20:49:27

Well, I didn't do anything special. Install from AUR, run with loliclip &, try to copy from Pidgin chat window - normally the selection shouldn't go away, but now it does and nothing is copied (most of the times - sometimes a couple of letters actually are put in the clipboard). I could try giving you output tomorrow if needed. You don't have Pidgin or can't reproduce?

Cloudef · 2013-08-01 06:43:36

I installed pidgin yesterday to try it out, but I could not reproduce it.

normally the selection shouldn't go away, but now it does and nothing is copied

That sounds like it's trying to follow PRIMARY for some reason.

Alien282 · 2013-08-01 07:39:24

Actually I was mistaken - the text is copied fine but cannot be PASTED in Pidgin - i.e. when copying FROM Pidgin and pasting IN Pidgin it doesn't work.

Here is the log. The first happens when I paste the thing I've copied ("Conversation") from Pidgin into something else:

-!- xcb: selection request
-!- UTF8 request
-!- check 12 bytes
-!- SENT: Conversation [12]
-!- SECONDARY [0]
-!- LOOP
-!- CLIPBOARD [0]
-!- LOOP
-!- Handle clipboard text/uri-list
-!- PRIMARY [0]
-!- BLOCK

While this is the output when I paste the same thing into Pidgin itself:

-!- xcb: selection request
-!- Special data request from text/html
-!- check 20 bytes
-!- SECONDARY [0]
-!- LOOP
-!- CLIPBOARD [0]
-!- LOOP
-!- Handle clipboard text/uri-list
-!- PRIMARY [0]
-!- BLOCK

Does that help?

Cloudef · 2013-08-01 07:51:23

i.e. when copying FROM Pidgin and pasting IN Pidgin it doesn't work.

I'll try this when I get home from work.

Alien282 · 2013-08-01 08:54:15

Sure, thanks. btw, a better mapping for Vim would be:

xnoremap <silent> <C-c> "zy:call system('loliclip -ci', @z)<cr>

I think it does the same thing and is way simpler?

Cloudef · 2013-08-01 14:53:37

I could reproduce this bug, and I'll investigate why it happens.
For now you can disable text/html special selection in config.h to workaround the issue.

Alien282 wrote:

xnoremap <silent> <C-c> "zy:call system('loliclip -ci', @z)<cr>
I think it does the same thing and is way simpler?

Indeed it does! I'll update it on first post.

Edit:
I've fixed this bug. Won't push yet however.
This is the same bug that affects blender text editor as well.
However it seems blender is somehow breaking X11 clipboard "standards" by throwing something that isn't utf8 to UTF8_STRING buffer.

Edit2:
Nope, I'm not doing enough sanity checks. Fixed.

I've pushed update to AUR. Does the delay issues still happen for you on gvim though?
I would love to have those fixed as well. And add support for the dynamic selections in future.

Last edited by Cloudef (2013-08-01 16:43:19)

Alien282 · 2013-08-02 08:49:15

Great, thanks for the fix, now it works fine!

I'm not sure whether the issue with vim happens, it's difficult to reproduce. Note that I am using this mapping so it is less likely to do so (I would imagine). If I were to use `xnoremap <C-c> "+y` then it might break more often as this will copy to the X CLIPBOARD and then loliclip might need time to copy it back to PRIMARY... did you do anything to "fix" that?

Cloudef · 2013-08-02 12:43:33

did you do anything to "fix" that?

No I din't, but "+y works quite fine here. So maybe you could try reducing the polling delays a bit?
I would like to avoid busy loops as much as possible to make loliclip idle at background.
(loliclip can perform select when it owns clipboard and primary, that effectively stops it from polling)

Alien282 · 2013-08-02 13:54:42

I don't understand. When does it "own clipboard and primary"? Does that have anything to do with reducing polling delays? I haven't tried to do that yet, but I will at some point. Anyway, thanks again and good luck improving loliclip! It's really great!

Cloudef · 2013-08-02 17:16:37

In X11, clients own and serve their own clipboards to other clients. When you own the clipboard, you can select for X11 event about clipboard ownership lost. (This means no polling.)
Loliclip takes the ownership of clipboard immediately, and primary after clipboard is synced to it. (without sync, primary ownership is never taken since applications lose selection visually causing breaking user interaction)

I think your gvim delay is caused by the polling though, so If you can play around with the values I told in earlier posts at some point, and post your insight that would be nice.

dumblob · 2013-08-08 08:39:08

Hi Cloudef, I really appreciate your work. Till now I used a few running instances of autocutsel to synchronize "every possible" clipboard/selection to each other. This solution though has one great disadvantage - it doesn't handle UTF-8 very well. After two years of using this approach I currently found loliclip, bud didn't figure out how to mimic the each-to-each selection synchronization principle. I've tried the following

   REGISTER_CLIPBOARD("PRIMARY",   "SECONDARY", 0, CLIPBOARD_OWN_IMMEDIATLY),
   REGISTER_CLIPBOARD("PRIMARY",   "CLIPBOARD", 0, CLIPBOARD_OWN_IMMEDIATLY),
   REGISTER_CLIPBOARD("SECONDARY", "PRIMARY",   0, CLIPBOARD_OWN_IMMEDIATLY),
   REGISTER_CLIPBOARD("SECONDARY", "CLIPBOARD", 0, CLIPBOARD_OWN_IMMEDIATLY),
   REGISTER_CLIPBOARD("CLIPBOARD", "PRIMARY",   0, CLIPBOARD_OWN_IMMEDIATLY),
   REGISTER_CLIPBOARD("CLIPBOARD", "SECONDARY", 0, CLIPBOARD_OWN_IMMEDIATLY),

which apparently doesn't do what I want. Neither different combinations of CLIPBOARD_OWN_IMMEDIATLY, CLIPBOARD_CLEAR_SELECTIONS and CLIPBOARD_NONE help.

Do you have any idea how to accomplish the desired behaviour?

Cloudef · 2013-08-08 09:24:22

@dumblob,
There will be problems, if you sync primary to something else.
Since loliclip owns the clipboards on every sync (for potential post-processing), you will visually lose the selection when this happens, making mouse selection impossible/pain.
I guess it could be possible to give flag to never own the clipboard until the owner of the selection dies, but that's not currently planned.

Otherwise that should work. I've never tested cross-syncing however, so there might be problems.

dumblob · 2013-08-08 19:25:04

Thank you @Cloudef! I'll be patient if you once find a bit of time to add such a flag. Maybe I'll look at your code and try to patch it myself, but 2500 lines of X11 code doesn't make me feel comfortable after my experience with X11 libraries

WonderWoofy · 2013-11-03 04:29:56

I really like this little piece of software. But I'm wondering if there is anyone else who experiences core-dumps frequently. The daemon doesn't seem to stop working, but I get a whole bunch of these all the time:

% systemd-coredumpctl                                                                                                                                                                          
TIME                                         PID   UID   GID SIG EXE
              Mon 2013-10-21 22:35:29 PDT   3479  1000   100  11 /usr/bin/loliclip
              Mon 2013-10-21 22:50:00 PDT    532  1000   100  11 /usr/bin/loliclip
              Tue 2013-10-22 16:55:41 PDT    535  1000   100  11 /usr/bin/loliclip
              Tue 2013-10-22 16:56:34 PDT    530  1000   100  11 /usr/bin/loliclip
              Tue 2013-10-22 17:14:59 PDT    530  1000   100  11 /usr/bin/loliclip
              Tue 2013-10-22 17:16:20 PDT    533  1000   100  11 /usr/bin/loliclip
              Tue 2013-10-22 17:27:43 PDT    534  1000   100  11 /usr/bin/loliclip
              Tue 2013-10-22 17:33:13 PDT    533  1000   100  11 /usr/bin/loliclip
              Tue 2013-10-22 17:34:33 PDT    520  1000   100  11 /usr/bin/loliclip
              ...

I haven't had any other signs of malfunction, so I haven't actually haven't looked into this at all. But I just noticed this when I had an issue with another program.

Cloudef · 2013-11-03 12:49:47

According to my systemd-coredumpctl, my last coredump was few months ago.

I looked at the loliclip's horrifying codebase and found at least issues with multibyte trimming code, and cleaned up some of the string handling as well.

If these issues continue, it seems systemd-coredumpctl can attach gdb to coredump. This will need debug symbols for meaningful trace however.

Also there might be chance that loliclip doesn't respond so well when X server dies.
If the coredumps still appear, you could try send gentle kill signal to loliclip before X server exits.

WonderWoofy · 2013-11-03 17:44:42

Neat, thanks for the quick response clouddef. I'll rebuild and put it back into service. I had switched to something else temporarily while I awaited insight into the issue. So we'll see how it goes. If problems persist (which, honestly, there were never any real problems from the perspective of daily use), I'll see about gathering some more debug info for you (and me).

0mark · 2013-11-04 11:18:46

I really like this, especially with when using luakit. The name though...

Well, in case that anyone else has gotten into trouble cause of the name, i made a decent named fork.

https://github.com/0mark/clipster

Unia · 2013-11-04 12:24:26

^ Please don't tell me you forked a project only to change it name?!

0mark · 2013-11-04 12:56:03

Unia wrote:

^ Please don't tell me you forked a project only to change it name?!

Usually i wont even bother to rename something at all. But in this case the name caused trouble, and can possibly cause serious trouble (luckily people asked before making conclusions). What would be a more appropriate Way?

I also added a Makefile

x33a · 2013-11-04 14:23:20

@ 0mark

Frankly, it would be better if Cloudef would choose a better name. Forking for the sake of the name is kind of bad, but I understand your point.

0mark · 2013-11-04 14:35:38

Now i feel a bit awkward. Indeed i should have asked first. Can do it now

@Cloudef: Would you mind to change the Projects name into something less easily to provoke trouble when seen somewhere from, for example, coworkers? (sorry for not asking in the first place, i just did not think enough)

Cloudef · 2013-11-04 14:43:35

Would you mind to change the Projects name into something less easily to provoke trouble when seen somewhere from, for example, coworkers? (sorry for not asking in the first place, i just did not think enough)

I don't see how the name is problem. But since it seems to cause problems somewhere, of course I can change it.
If it's okay I can take your makefile as well and move it to own git repo from my PKGBUILD's repo.

However clipster doesn't sound that well to my ear (reminds me of hipster).
If you are fine with it I would like to suggest 'xcmenu' as alternative name that is basically short from "X clipboard menu".

0mark · 2013-11-04 14:58:55

Cloudef wrote:

Would you mind to change the Projects name into something less easily to provoke trouble when seen somewhere from, for example, coworkers? (sorry for not asking in the first place, i just did not think enough)
I don't see how the name is problem. But since it seems to cause problems somewhere, of course I can change it.

Well, at least in germany "loli" is considered some kind of porn with minors (or something alike), while "clip" is a short movie.

Cloudef wrote:

If it's okay I can take your makefile as well and move it to own git repo from my PKGBUILD's repo.

Sure, would be great.

Cloudef wrote:

However clipster doesn't sound that well to my ear (reminds me of hipster).
If you are fine with it I would like to suggest 'xcmenu' as alternative name that is basically short from "X clipboard menu".

Sounds good

PS: You are right, clipster really sounds like hipster, dont know how i missed that.

Arch Linux

#201 2013-07-31 16:56:14

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#202 2013-07-31 17:16:30

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#203 2013-07-31 20:49:27

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#204 2013-08-01 06:43:36

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#205 2013-08-01 07:39:24

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#206 2013-08-01 07:51:23

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#207 2013-08-01 08:54:15

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#208 2013-08-01 14:53:37

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#209 2013-08-02 08:49:15

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#210 2013-08-02 12:43:33

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#211 2013-08-02 13:54:42

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#212 2013-08-02 17:16:37

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#213 2013-08-08 08:39:08

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#214 2013-08-08 09:24:22

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#215 2013-08-08 19:25:04

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#216 2013-11-03 04:29:56

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#217 2013-11-03 12:49:47

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#218 2013-11-03 17:44:42

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#219 2013-11-04 11:18:46

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#220 2013-11-04 12:24:26

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#221 2013-11-04 12:56:03

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#222 2013-11-04 14:23:20

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#223 2013-11-04 14:35:38

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#224 2013-11-04 14:43:35

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

#225 2013-11-04 14:58:55

Re: xcmenu - lightweight clipboard manager for X (formerly loliclip)

Board footer