xcmenu - lightweight clipboard manager for X (formerly loliclip)

Unia · 2013-11-04 15:22:25

Aaaaand all is well that ends well!

Cloudef · 2013-11-04 15:59:06

Aaand done.

The standalone git repository is now here: https://github.com/Cloudef/xcmenu
The git PKGBUILD can be found from either AUR or from my PKGBUILDs repository.

Updating to xcmenu is highly recommended for future updates.
To carry over your history do: mv ~/.local/share/loliclip ~/.local/share/xcmenu

x33a · 2013-11-04 16:38:36

That was fast!!

Just because of your super responsive attitude, I'll have to give it a try, I guess.

Edit:

In your edited initial post (thread starter), in the following line:

'You should update to use the new xmenu package instead.'

It should say xcmenu instead.

Last edited by x33a (2013-11-04 16:43:12)

Cloudef · 2013-11-04 17:18:14

In your edited initial post (thread starter), in the following line:
'You should update to use the new xmenu package instead.'
It should say xcmenu instead.

Thank you, I have fixed this.

WonderWoofy · 2013-11-04 19:03:10

Neat! I have thought about the potential name problem of loliclip in the past, but never thought it was worth mentioning. xcmenu is a nice name though, and it is nice to have the AUR PKGBUILD actually pull from your git repo instead of having it packaged with the tarball.

Maybe you should append "(formerly loliclip)" to the title of the thread... at least for a little while. That way those familiar with your great little piece of software will still be able to find it.

Cloudef · 2013-11-04 19:13:55

Maybe you should append "(formerly loliclip)" to the title of the thread... at least for a little while. That way those familiar with your great little piece of software will still be able to find it.

Done

AloisJanicek · 2013-11-08 19:56:05

I've been using clipit with automatic primary selection sync settings. Every text which I select is stored in clipit's history. I like it.
Is possible mimic this behavior with xcmenu? I've been looking into config.h but without success, I probably don't understand this clipboard stuff correctly.

EDIT: So I just adopted your workflow from first post in this thread and I am happy about it. Many thanks for sharing your work! ;-)

Last edited by AloisJanicek (2013-11-08 20:35:43)

sekret · 2013-11-10 12:53:59

I'd put a

replaces=('loliclip' 'loliclip-git')

in the PKGBUILD

Cloudef · 2013-11-10 13:56:33

Done.

triplc · 2013-11-29 16:31:56

Hi Cloudef,

I just discover that xcmenu is so GREAT.

Just a small thing: when xcmenu is running as daemon, and in an typical editor (example leafpad) select text and press Ctrl-C, then the hi-light of that selection is cleared, which is quite anoying. I often look at that high-light to make sure that Ctrl-V was not pressed accidently. I do know much about programming. Can you have a look to see why.

Last edited by triplc (2013-11-29 16:33:34)

WonderWoofy · 2013-11-29 18:25:07

I think I should probably mention that it would indeed seem as though my coredumps are an issue with how I run and exit X. So no real issue here. Thanks again for the badass clipboard manager CloudDef!

Cloudef · 2013-11-29 19:18:03

@triplc,
This is the default behaviour in xcmenu.
xcmenu by default post-processes your clipboard text by removing whitespace (from non multiline stuff) and trailing newlines. This requires it to own the selection immediately in X level though, which causes the highlight lose visually.

If you don't care about post-processing of your text, then remove the lines 55-57 in config.h.
I haven't tested, if that does the trick anymore. But it should.

triplc · 2013-11-30 00:23:44

Yes! It works. Thanks.
Turn off clipboard automatic space trim is also needed when editing source code, because those spaces are used for indent.

Cloudef · 2013-11-30 22:00:42

Yes! It works. Thanks.

Great!

Turn off clipboard automatic space trim is also needed when editing source code, because those spaces are used for indent.

Vim handles those for me, it's disabled on multiline pastes by default though just for this reason.

tonk · 2013-12-16 07:40:47

Works great, using it for a few months now. Just one problem. Is it possible to disable it for some applications (or change the behavior for copied bézier curves)? In this case inkscape. It'll paste bitmap images instead of paths.

Cloudef · 2013-12-16 07:49:07

Most likely needs another special selection specified in config.h, you can find name for that using the python script provided in git.
Still haven't got time to do dynamic insertion for these when the special selections are used. I've had ideas to do application specific ignore rules as well, but yeah..

likytau · 2013-12-29 21:48:11

Hi, I've just started using xcmenu and am very pleased with it's ability to receive and provide image files. However, I'd like to disable xcmenu at selected times because it really slows things down when I copy large image areas (~1000x1000).

My initial try at this involved Ctrl+Z/SIGSTOP-ing xcmenu. This appears to work okay; it behaves as expected when I SIGCONT it. Are there any reasons to avoid this method?

One other question I have is about listing the available binary selections -- is it currently possible to do this? I've tried

xcmenu --binary --list

and

xcmenu --list --binary

-- the latter complains --list is not a selection target, the former is no different from plain --list.

likytau · 2014-01-07 21:32:43

Actually, ctrl+Zing it is not okay. It gets confused, X gets confused.. eventually it's resolved but no, that does not work.

Also, xcmenu eats Editra's clipboard. Not sure what is going on there, but when you cut and paste, the paste operation pastes nothing. I don't really know which tools are needed to debug X selections.

Cloudef · 2014-01-07 21:40:05

@likytau, for post processing xcmenu own the selection immediatly unlike the other clipboard managers. (Thus when you copy, the contents immediately gets transfered to xcmenu (which can be slow due to how X clipboard works))
https://bbs.archlinux.org/viewtopic.php … 5#p1354995 the configuration change here should make it not own immediately (you'll lose post-processing etc..)

To see available selections see config.h or just type xcmenu -h (Valid arguments for the --binary switch:)

Editra may use target that xcmenu doesn't know of, or doesn't expect another application to get the selection immediately thus not playing well. The unknown target can be solved by adding new target to config.h, this will someday become unnecessary when I add dynamic target query.

As for stopping xcmenu, I haven't tested that. I might add list to config.h where xcmenu will stop handling clipboard from certain programs.

Last edited by Cloudef (2014-01-07 21:42:40)

likytau · 2014-01-08 04:33:31

It seems I've been unclear: I hope to get a list of the actual binary data that xcmenu currently 'owns'.. for example that it has a 50k png, or a 5k svg, etc.. and some way to ask for a particular one.
Maybe I am misunderstanding how binary selections work, but I thought xcmenu tracked selection history? (so that I could ask for the most recent png, or a few older ones, etc).

Thanks for the tip on not owning immediately -- I can do without the postproc even for code, if it makes the image copy performance better.

In regards to stopping handling clipboard from certain programs, that probably would have no effect in my case, since I normally want xcmenu to intercept image copies from GIMP and MyPaint, it is just when I get into high res stuff that xcmenu causes significant slowing.

Cloudef · 2014-01-08 12:01:21

It seems I've been unclear: I hope to get a list of the actual binary data that xcmenu currently 'owns'.. for example that it has a 50k png, or a 5k svg, etc.. and some way to ask for a particular one.
Maybe I am misunderstanding how binary selections work, but I thought xcmenu tracked selection history? (so that I could ask for the most recent png, or a few older ones, etc).

It doesn't track history for binary selections for now. It might be added future for selections that are below specified size with max history size range.

Thanks for the tip on not owning immediately -- I can do without the postproc even for code, if it makes the image copy performance better.

Yeah, with not owning immediately, the image data stays in gimp (thus "copying" is fast) and is only sent to somewhere else when you try to paste the image to another application, or quit gimp (then it goes to xcmenu).

In regards to stopping handling clipboard from certain programs, that probably would have no effect in my case, since I normally want xcmenu to intercept image copies from GIMP and MyPaint, it is just when I get into high res stuff that xcmenu causes significant slowing.

Seems like you'll need command line switch to pause the daemon gracefully then. I'll keep that in mind as well.

Last edited by Cloudef (2014-01-08 12:03:25)

F34R · 2014-01-08 17:02:01

Can as possible working with dmenu and mpc ( like lolimpd)?

Rasi · 2014-01-09 04:55:06

I will have to try this... sounds cool

Last edited by Rasi (2014-01-09 04:56:02)

WonderWoofy · 2014-01-09 05:09:32

@cloudef, I think it has been long enough that maybe you should ask to have loliclip removed. Just a thought...

zeltak · 2014-01-25 18:18:44

Cloudef
hi, would you consider adding snippets like function to xcmenu? where one could add often used commands and they would be stored in memory and called and pasted when needed?

best

Z

Arch Linux

#226 2013-11-04 15:22:25

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

#227 2013-11-04 15:59:06

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

#228 2013-11-04 16:38:36

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

#229 2013-11-04 17:18:14

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

#230 2013-11-04 19:03:10

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

#231 2013-11-04 19:13:55

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

#232 2013-11-08 19:56:05

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

#233 2013-11-10 12:53:59

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

#234 2013-11-10 13:56:33

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

#235 2013-11-29 16:31:56

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

#236 2013-11-29 18:25:07

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

#237 2013-11-29 19:18:03

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

#238 2013-11-30 00:23:44

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

#239 2013-11-30 22:00:42

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

#240 2013-12-16 07:40:47

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

#241 2013-12-16 07:49:07

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

#242 2013-12-29 21:48:11

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

#243 2014-01-07 21:32:43

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

#244 2014-01-07 21:40:05

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

#245 2014-01-08 04:33:31

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

#246 2014-01-08 12:01:21

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

#247 2014-01-08 17:02:01

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

#248 2014-01-09 04:55:06

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

#249 2014-01-09 05:09:32

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

#250 2014-01-25 18:18:44

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

Board footer