Any chance someone can post what config.h one can use to get a similar behaviour to klipper?
Ie, if I select text in terminal, it doesn't automatically store it in the xcmenuctrl (clipboard?) list?
Secondly, when via the dmenu (calling xcmenuctrl) selecting some entry and trying to paste, sometimes it doesn't work, not quite sure why.
]]>best
Z
]]>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.
]]>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.
]]>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.
]]>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.
]]>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.
]]>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.
]]>