Add dedicated dragging state for slider widget

[sclu1034]

When trying to hook up the slider to an external value, one would usually have two data streams:

• property::value -> set external value
• external value changed -> .value = new_value

The problem is that without manual intervention, these two streams form a loop, as setting .value also emits property::value.

Having a dedicated "dragging" state with associated signals disconnects these data streams.

[codecov[bot]]

Codecov Report

Merging #3533 (741764a) into master (70524e7) will increase coverage by 0.00%. The diff coverage is 98.57%.

@@           Coverage Diff            @@
##           master    #3533    +/-   ##
========================================
  Coverage   90.66%   90.67%            
========================================
  Files         852      855     +3     
  Lines       54440    54843   +403     
========================================
+ Hits        49358    49727   +369     
- Misses       5082     5116    +34     

Flag	Coverage Δ
gcov	90.67% <98.57%> (+<0.01%)	:arrow_up:
luacov	93.49% <98.57%> (-0.01%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
lib/wibox/widget/slider.lua	96.79% <85.71%> (+7.34%)	:arrow_up:
tests/test-wibox-widget-slider.lua	100.00% <100.00%> (ø)
spec/wibox/test_utils.lua	51.96% <0.00%> (-27.78%)	:arrow_down:
tests/examples/wibox/widget/defaults/slider.lua	95.65% <0.00%> (-4.35%)	:arrow_down:
spawn.c	82.58% <0.00%> (-3.51%)	:arrow_down:
systray.c	91.12% <0.00%> (-1.33%)	:arrow_down:
themes/xresources/theme.lua	88.65% <0.00%> (-0.93%)	:arrow_down:
awesome.c	80.80% <0.00%> (-0.78%)	:arrow_down:
lib/awful/widget/taglist.lua	88.73% <0.00%> (-0.06%)	:arrow_down:
objects/client.h	62.50% <0.00%> (ø)
... and 23 more

[Elv13]

Thanks for this. Too bad testing this would be rather non trivial. If you want to do it, you could copy/paste test-awful-widget-button.lua and replace the button with the slider.

[sclu1034]

The test runs fine when executed solo (./tests/run.sh test-wibox-widget-slider.lua) and it uses the same fake input as test-awful-widget-button.lua, so no clue why it fails when run as part of the full set of tests.

[Elv13]

Usually, you have to check for completion in each step or return nil. This wait another event loop iteration and try again. A lot of XCB is async, so those things are not deterministic. Each step is retried 10 time when it returns nil. Adding sync should not be necessary, but is done in a few places.

I would also appreciate not adding a new hard dependency here. Even busted is optional. Many distribution package awesome and run the tests as part of the build process. Adding a new dep will potentially delay the packaging of 4.4 "because it's harder than changing the version number of the spec/control/pkgbuild file".

[sclu1034]

Replaced the assert.spy with the got_called = true tests, as already used in test-awful-widget-button.lua.

[Elv13]

The failure is strange. I am not so sure. Maybe adding a couple empty steps after the wibox creation might help (there is a bunch of potentially async stuff going on before the widget is displayed, so the step might win or lost a race with other delayed calls?). It's 2:30 am here. I will see if I can reproduce it tomorrow.

[sclu1034]

Spent some more time trying to investigate why the signals don't fire in the tests.

A simple function like this works perfectly fine locally, both in Xephyr and Xvfb:

-- Same wibox+slider+signals setup as in the test's first step
gears.timer.delayed_call(function()
	mouse.coords({ x = 12, y = 24 })
	root.fake_input("button_press", 1)
	mouse.coords({ x = 100, y = 24 })
	root.fake_input("button_release", 1)
end)

So clearly, async is not the issue and no waiting between those actions is necessary for the individual signals to fire. They do only fire after the step that triggered them has finished, but that's fine, as long as triggering and checking are two separate steps.

The actual reason why no signals fired in CI is that the mouse never actually hit the widget. I don't know why, but the position at which the wibox is placed is not always consistent with what x and y are set to.