Add QmlControlProxy::trigger()

[JoergAtGithub]

This PR adds a trigger method to QmlControlProxy. This is using a single shot timer with zero interval, to ensure that both updates (1 then 0) will correctly be reported to the CO slots, as two seperate events in the event loop.

[Swiftb0y]

IMO it would be better if trigger just emitted the controls valueChanged signal.

[JoergAtGithub]

IMO it would be better if trigger just emitted the controls valueChanged signal.

@acolombier wrote in #14849 (comment) that both states are important for property binding. Therefore I implemented it this way.

[acolombier]

I believe you might be able to also emit the two signals back to back so they both get addressed in the eventloop, in case you don't want to use the timer.

Thanks for looking into this! <3
I'll check it when I'm back at my keyboard

[Swiftb0y]

IMO it would be better if trigger just emitted the controls valueChanged signal.

@acolombier wrote in #14849 (comment) that both states are important for property binding. Therefore I implemented it this way.

Right, thanks for the pointer. I still didn't find a way where this was actually required. I can only find this used for the "eject" control.

mixxx/src/widget/wtrackmenu.cpp

Lines 2571 to 2572 in 3c35370

	ControlObject::set(ConfigKey(group, "eject"), 1.0);
	ControlObject::set(ConfigKey(group, "eject"), 0.0);

IMO we should first fix the eject CO behavior and then see if the double value in the event loop is required anywhere else. I think the primary issue stems from the fact that "eject" is set up as ControlPushButton, even though it really only behaves as a basic signal in practice.

[acolombier]

AFAIS, this snippet would indeed induce two consecutive emits (one for 1.0, one for 0.0) which should indeed be sufficient for the property binding to detect this trigger!

So in theory, you should be able to remove the QTimer and have two consecutive setValue

[JoergAtGithub]

IMO we should first fix the eject CO behavior and then see if the double value in the event loop is required anywhere else. I think the primary issue stems from the fact that "eject" is set up as ControlPushButton, even though it really only behaves as a basic signal in practice.

We've also

mixxx/res/controllers/common-controller-scripts.js

Lines 265 to 271 in 6adb012

	script.triggerControl = function(group, control, delay) {
	if (typeof delay !== "number") {
	delay = 200;
	}
	engine.setValue(group, control, 1);
	engine.beginTimer(delay, () => engine.setValue(group, control, 0), true);
	};

Which is used for many other controls:
https://github.com/search?q=repo%3Amixxxdj%2Fmixxx+path%3A%2F%5Eres%5C%2Fcontrollers%5C%2F%2F+triggerControl&type=code

Why do you think this is specific for "eject" ?