GNOME Bugzilla – Bug 761208
Slider widget does not emit a drag-begin signal
Last modified: 2016-01-28 12:20:19 UTC
I noticed that the Slider widget (js/ui/slider.js) emits 'value-changed' and 'drag-end' signals but does not emit 'drag-begin', which could be handy in cases where you want to allow a different behaviour while the value is changing depending on whether the user is explicitly dragging (click + drag) the slider or not (e.g. using the mouse-wheel). For instance, that would be handy for a extension I'm writing [1], where I want precisely to do that: only update the value of the text-scaling-factor GSetting key on 'value-changed' if NOT dragging, to avoid a very unpredictable behaviour that would happen if I allowed that. This would be a really small change in slider.js that should be useful while not breaking anything, so I'll be proposing a patch soon after filing this report. [1] https://extensions.gnome.org/extension/1018/text-scaler/
Created attachment 319883 [details] [review] Patch proposal Small patch as promised. I tested this with my extension and logging events to the journal and it works exactly as I would expect it to. Please review, thanks!
Review of attachment 319883 [details] [review]: ::: js/ui/slider.js @@ +229,3 @@ this._value = Math.max(0, Math.min(this._value + delta, 1)); this.actor.queue_repaint(); + this.emit('drag-begin'); I think it's questionable to treat some events as drags (key presses) but not others (pointer scroll), but that's already the case without this patch, so OK
I thought the same, but as you said this was the case already, so I limited the patch to make it consistent (and it needed a drag-begin here, as there's a drag-end right afterwards), not to potentially break things that might be relying on that already. Thanks for the review, I've just committed it now: https://git.gnome.org/browse/gnome-shell/commit
https://git.gnome.org/browse/gnome-shell/commit/?id=779b1ae8e565087de2203486e4f81288fb6a4aec