Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have "changing" and "changed" signals in Range controls #6007

Closed
Zylann opened this issue Aug 2, 2016 · 10 comments · Fixed by #55775
Closed

Have "changing" and "changed" signals in Range controls #6007

Zylann opened this issue Aug 2, 2016 · 10 comments · Fixed by #55775

Comments

@Zylann
Copy link
Contributor

Zylann commented Aug 2, 2016

Currently, there is only one value_changed signal in Sliders, which is called continuously as the user drags the thumb. This is fine to be able to see the change as we change the value, however when the change is heavy, having it to update continuously results in lag.

The idea is to have two signals then:
changing which is called when the value changes,
changed when the user finished to drag the slider, OR, has clicked once without dragging (having also changed the value).
Names aren't specially important, just pick some that make sense.

Note: I think it would also make UndoRedo easier to implement because we would know when editing finishes.

@timoschwarzer
Copy link
Contributor

I would keep value_changed and add two new signals like drag_started and drag_stopped.
1st this would be backwards compatible and actually the value is being changed while you are dragging.

@EveAwesome
Copy link

personally, I'd prefer released() as suggested in closed issue 7056

@Favorlock
Copy link

Is this being addressed at all?

@Calinou
Copy link
Member

Calinou commented Apr 3, 2020

@Favorlock It seems nobody is currently working on this feature. Pull requests are welcome 🙂

I'd go for adding new drag_started and drag_stopped signals so this can be backwards-compatible. This way, we could cherry-pick the change into 3.2.x.

@Zylann
Copy link
Contributor Author

Zylann commented Apr 3, 2020

I slightly updated the first post as I had this use case again but had to clarify something. It's not just about dragging

@lupoDharkael
Copy link
Contributor

lupoDharkael commented Apr 23, 2020

For mouse detection I'd add slider_pressed and slider released.

Maybe we could approach this the Qt way and implement a tracking property, if tracking is false value_changed is only emitted when we change the value with keyboard or when we finish moving the slider with the mouse. With tracking set to true the signal would behave the same as the actual implementation.

They also define a signal called sliderMoved(value) which emits the value inconditionally and it serves to preview the changes even with tracking set to false as it would only notify a value at the end of the user interaction.

@Giwayume
Copy link
Contributor

Can I request the slider documentation be updated with the list of signals as well? I have great difficulty finding which signals are available for controls.

https://docs.godotengine.org/en/3.2/classes/class_slider.html#class-slider

@akien-mga
Copy link
Member

@Giwayume All signals are in the documentation. Slider doesn't have specific signals, all its signals are inherited from Range, Control, etc.

Click the classes in the "Inherits" line for the documentation of each parent class.

@vortex-captain
Copy link

I found a GDScript solution, which works fine with mouse dragging (not tested on a touchscreen though)

extends VSlider

signal drag_started
signal drag_stopped

func _input(event):
	if event is InputEventMouseButton:
		if event.is_pressed():
			emit_signal("drag_started")
		else:
			emit_signal("drag_stopped")	

reference: https://stackoverflow.com/a/51687109

@Zylann
Copy link
Contributor Author

Zylann commented Nov 27, 2020

This is going to emit even when the value didn't change. Also I'm not sure it will work properly with spinboxes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.