Implement xcb input shapes

[DziubanMaciej]

[actionless]

please include your test app (https://github.com/awesomeWM/awesome/issues/4035#issuecomment-3488255106) in a similar way how xeyes is being tested

example of test app built for test: https://github.com/search?q=repo%3AawesomeWM%2Fawesome%20test-systray.c&type=code

[actionless]

also speaking of tests, i also see some of the existing ones are failing

[DziubanMaciej]

please include your test app (#4035 (comment)) in a similar way how xeyes is being tested

example of test app built for test: https://github.com/search?q=repo%3AawesomeWM%2Fawesome%20test-systray.c&type=code

Hmm, but xeyes is just launched, not really tested. The comment states that it exists just to stabilize code coverage. Is it even worth to add my app if we won't test it?

[actionless]

unlike xeyes, your case actually testable - you could return specific exit code in your app if it being clicked in that shaped surface - and assert in test for that exit code

[actionless]

(and also test that when clicked outside of area - it not registers input, e.g. not exiting with that code)

[DziubanMaciej]

Okay, I guess you're right. But how would I simulate the click? There are not many tests that call external processes (only test-systray and test-gravity) and none of them do it.

[actionless]

there are plenty of other tests who simulate clicks, here's the most canonical example: https://github.com/awesomeWM/awesome/blob/bc57f0ff3678f71a09f919019677e4192533f713/tests/test-wibox-shape.lua#L51-L68

[DziubanMaciej]

Yeah, but they don't spawn external processes... They create wiboxes which I assume is fully synchronous. It seems a lot simpler.

In my case I would have to spawn the process and then wait until it's initialized and can actually receive mouseclicks, wouldn't I? Otherwise the simulated clicks could be signaled before the process even initialized X11 and they would be lost.

Also, how would I detect that the window was not clicked? The test you sent relies on click count, but again, it looks like it's synchronous.

[actionless]

there is count function argument which is used for async tests, see here for example:

https://github.com/awesomeWM/awesome/blob/master/tests/test-spawn.lua

[actionless]

Also, how would I detect that the window was not clicked?

by placing wibox below the window and catching or not catching the click on it, and double-checking afterwards during the next 'count' that click wasn't received by the app as well (e.g. it still didn't exited with 'click exit code')

[actionless]

just a small word of additional explanation - for handling async case, the sync test is being started over and over (increasing count argument), until test would return smth useful or crash

[DziubanMaciej]

Yeah, the count parameter confused me greatly at first, but now I get it :D

Alright, I added the test as you proposed. Wibox is behind the test app. I'm simulating clicks and expecting them to happen either in wibox (detected with a signal) or in the app (detected in app's stdout).

When I click manually, it behaves correctly. However, fake clicks on the app don't work for some reason. Neither wibox nor app receives it. If I click on the app manually before the fake click, then it works. The first manual click isn't detected by the app. It's as if this first click "activates" the window. Why could it be? I tried to forcefully focus and raise the app window, but it doesn't help.

Could you take a look?

[actionless]

If I click on the app manually before the fake click, then it works. The first manual click isn't detected by the app

mb try to do nothing on first/few count, and try clicking when count is more than that

[DziubanMaciej]

If I click on the app manually before the fake click, then it works. The first manual click isn't detected by the app

mb try to do nothing on first/few count, and try clicking when count is more than that

I added a sleep(2) and it's still not enough. I don't think it's a timing issue. Some awesome's state must be left not updated or something.

[codecov[bot]]

Codecov Report

:x: Patch coverage is 96.61017% with 2 lines in your changes missing coverage. Please review. :white_check_mark: Project coverage is 54.50%. Comparing base (d37e3c6) to head (b853d7e). :warning: Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
event.c	0.00%	1 Missing and 1 partial :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4036      +/-   ##
==========================================
+ Coverage   54.25%   54.50%   +0.25%     
==========================================
  Files         261      263       +2     
  Lines       31173    31255      +82     
  Branches     1143     1145       +2     
==========================================
+ Hits        16912    17037     +125     
+ Misses      13751    13711      -40     
+ Partials      510      507       -3     

Files with missing lines	Coverage Δ
lib/awful/client/shape.lua	75.36% <100.00%> (+32.73%)	:arrow_up:
objects/client.c	80.25% <100.00%> (+1.27%)	:arrow_up:
tests/examples/shims/client.lua	27.19% <100.00%> (+0.32%)	:arrow_up:
tests/test-client-shape-input.c	100.00% <100.00%> (ø)
event.c	72.36% <0.00%> (-0.29%)	:arrow_down:

... and 15 files with indirect coverage changes

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[DziubanMaciej]

@actionless I think it's good now. The coverage report doesn't detect anything new.

[actionless]

please squash into one commit (or wait til this one get merged 😸 https://github.com/awesomeWM/awesome/pull/4040 )

[DziubanMaciej]

Already squashed. I got hit with the "check previous commits" check yesterday

[actionless]

great, thanks! then that's all from my side 👍

[DziubanMaciej]

@Aire-One, could you review this PR? Thanks!

[DziubanMaciej]

:(