Slider dragging signals #3884
Slider dragging signals #3884
Conversation
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`. The new set of signals is disconnected from the `value` property and its signal and allows for more fine grained inspection of the dragging state. Signed-off-by: Lucas Schwiderski <lucas@lschwiderski.de>
Signed-off-by: Lucas Schwiderski <lucas@lschwiderski.de>
Elv13
changed the title
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3884 +/- ##
==========================================
+ Coverage 91.22% 91.25% +0.03%
==========================================
Files 927 928 +1
Lines 59450 59522 +72
==========================================
+ Hits 54232 54317 +85
+ Misses 5218 5205 -13
Flags with carried forward coverage won't be shown. Click here to find out more.
|
In CI, the wibox doesn't always seem to be in the same location. So before the actual test steps, we need to find it first.
Elv13
force-pushed
the
feature/slider
branch
from
4d9ea87
to
eaff8aa
Compare
|
I mean, you already went as far as creating an entire copy of the PR to implement your own version before I even got to answer that question, which appears to me like my answer won't really affect much. Users expect to be able to set a value for a property (except for the client properties where X11 dictates otherwise) and to get a corresponding signal on change (which still applies for those X11 properties). |
Copy of #3533
Changed the
:is_dragging()method to be a property and fixluacheckwarnings.@sclu1034 Are you fine with this? This address a comment I left (and then forgot about) in the other PR.