Add selection getter objects

[psychon]

This fixes a large part of #492. Namely, this PR adds the "paste" part of "copy&paste". Also, this complements #2638 which is the PR that adds notifications for when some selection changes.

Simple usage example:

    local s = selection_getter("CLIPBOARD", "UTF8_TEXT")
    s:connect_signal("data", function(data) print("got data", data) end)
    s:connect_signal("data_end", function() print("data end") end)

The "data" signal is emitted for each piece of data that is received. After everything was received, "data_end" is emitted.

Simple example showing how to get the list of supported targets (in this case the argument is a table with the list of supported targets; everything else is (currently) a string):

    local s = selection_getter("CLIPBOARD", "TARGETS")
    s:connect_signal("data", function(d) gears.debug.dump(d) end)
    s:connect_signal("data_end", function() print("data end") end)

This has only received minimal testing so far...

[Elv13]

/me is busy right now, will check this weekend, but thanks for this, great work

[codecov]

Codecov Report

Merging #2639 into master will increase coverage by 0.12%.
The diff coverage is 98.53%.

@@            Coverage Diff             @@
##           master    #2639      +/-   ##
==========================================
+ Coverage   85.22%   85.34%   +0.12%     
==========================================
  Files         515      519       +4     
  Lines       34849    35186     +337     
==========================================
+ Hits        29701    30031     +330     
- Misses       5148     5155       +7

Flag	Coverage Δ
#c_code	74.32% <97.24%> (+0.55%)	⬆️
#functionaltests	70.47% <100%> (+0.24%)	⬆️
#lua53	85.34% <98.53%> (+0.12%)	⬆️
#samples	72.74% <ø> (-0.02%)	⬇️
#themes	49.03% <ø> (-0.03%)	⬇️
#unittests	58.38% <ø> (ø)	⬆️

Impacted Files	Coverage Δ
tests/test-selection-getter.lua	100% <100%> (ø)
luaa.c	69.74% <100%> (+0.17%)	⬆️
event.c	72.48% <100%> (+0.3%)	⬆️
property.c	79.62% <100%> (+0.09%)	⬆️
objects/selection_getter.c	97.16% <97.16%> (ø)
lib/menubar/utils.lua	57% <0%> (-0.2%)	⬇️
spec/menubar/utils_spec.lua	100% <0%> (ø)	⬆️
globalconf.h	100% <0%> (ø)	⬆️
tests/test-selection-watcher.lua	93.1% <0%> (ø)
... and 7 more

[Elv13]

Nice work. Right, this will need some abstraction layer(s). The useful bits are all there, async and all. With some way to set the selection and swap the PRIMARY, SECONDARY and CLIPBOARD buffers, it would be perfect (this is outside the scope of the pull request).

[Elv13]

Thanks for the changes

[blueyed]

@psychon
Thanks for this.
Would it be possible to get information about the client that owns the clipboard/selection also?
(I am interested in the pid mainly, but that could be queried via c.pid then.)

[psychon]

Uhm... nope, not really. We can query the selection owner, but that only gives us a window. I just tried with GVim and this is all the information that you can get from the selection owner info:

$ xprop -id 0x3800009
$

(Yes, there really is not a single property)

In theory, all of the things that are listed in ICCCM can be queried: https://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2

For example, NAME and HOST_NAME can be queried as per ICCCM. However, GTK does not seem to automatically supply them, so they are in practice not supported. Same for Qt.

[actionless]

mb lua code could iterate through all the windows and match the id?

[blueyed]

IIRC this is just a special window only for the selection, isn't it?

[psychon]

IIRC this is just a special window only for the selection, isn't it?

Yup.

You could try matching for closest window ID, but that means that you end up with "just a random window" for xclip. Plus, when a X11 client runs out of the XID space that the X11 server allocated at connection time, the client can ask for a new space. Thus, I'm not even sure if "closest XID" would always work.

[actionless]

btw, just very curious what is the usecase for that

[blueyed]

@actionless
awesomeWM/awesome-www#111 - I guess it is quite out of date online, but currently I am basically spawning xclip for both the selection and clipboard before sending SIGSTOP, so that trying to use the clipboard/selection does not "freeze" when the process is stopped.
But that is sometimes still a bit wonky, I guess when the SIGSTOP happens before xclip really takes ownership etc, so I've thought knowing about the owner would help in that case.