Button behavior when started as child

[kproth]

I'm working on a change related to external input and toggle buttons, for my own use (though I hope to offer it back to the community at some point). While working on my change, I noticed an existing behavior that doesn't seem quite right to me. Can anyone weigh in on what the right behavior should be?

By way of background, the scenario in question relates to Buttons tied to functions that are started as a child of a chaser or collection function, and a difference in subsequent behavior if the button is in a soloframe or isn't.

Here's the behavior that does make sense to me:

• If the button's function was started as a child of another function, the button gets a yellow border and has state=Monitoring.
• If the button's function was started by toggling the button directly, the button gets a green border and has state=Active.
• If the button lives in a SoloFrame, then whenever it goes to either Monitoring *or* Active state, any other button goes inactive (even if it was started by another function outside the soloframe).
• If you toggle a button that is yellow (Monitoring), it changes to green (Active).

Now, here's where my uncertainty comes in:

• If I've toggled a yellow button to green and it's in a soloframe, I canNOT toggle it off as long as the other function is still telling the button's function to be On. Though if I turn off the "parent" function, the button stays Green but can now be toggled off successfully.
• By comparison, if I've toggled a yellow button to green that is NOT in a soloframe, toggling it again will turn it OFF (make it go Inactive), even if the "parent" function is still active.
• The difference in behavior between being in a soloframe or not is what I'm questioning.
• Also, the observed behavior doesn't seem to match the comment in the vcbutton code.

The line of code that prevents toggling it off when in a soloframe is at vcbutton.cpp:688. The comment here talks about special behavior when a button is in a soloframe and startedAsAChild, which is supposed to stop "other functions" in the same solo-frame and start the one for the button that was just toggled. But, the code doesn't seem to match the comment. Note that this code came with the original fork of QLC+, so it's been there forever. Notably, it was in place before the button changed to being tri-state (Active/Monitoring/Inactive), so it used to key off of whether the button was "setOn()", which I assume would have been true if the button's function was running due to a parent function or due to a direct toggle.

In my head, since I can toggle a yellow button to green, it seems natural that I should then be able to return a green button to yellow by toggling it, if the other parent function is still telling the button's function to be running. But this isn't currently possible, regardless of where the button lives.

Alternately, if a button's function should be able to be toggled off by clicking on a green button, regardless of whether another parent function wants it to be active, that should work the same whether the button is in a soloframe or isn't.

Do either of the above two options sound more right than the current behavior?

I'm game for trying to make these buttons behave more consistently, but I don't want to make the wrong assumption about how it's supposed to work!

Thanks!

[kproth]

I just took a shot at testing this same scenario on v5. It behaves rather differently in this same scenario, in a good way. Specifically:

• A green/Active button that also has a chaser telling it to run can be fully stopped with a toggle, regardless of whether it's in a soloframe or not. This was my alternate thought of the right behavior above.
• But also, when a button in a soloframe goes yellow/Monitoring (i.e. due to its function being started by a chaser), it does NOT "take over" the solo function in the frame - if another button is already Green/Active, it will stay green/active.

I will probably attempt to replicate this same behavior in v4 when I submit my other change.

[GGGss]

But also, when a button in a soloframe goes yellow/Monitoring (i.e. due to its function being started by a chaser), it does NOT "take over" the solo function in the frame - if another button is already Green/Active, it will stay green/active.

Then v5 behavior is wrong. IMHO it is important to have the button in a solo behave as a master indifferent of its earlier state.

It is the sole possibility to reset x number of frames with a single button. (by loopback magic, you can reset all frames just by a single click).

[kproth]

Thanks for the reply. I want to make sure we're not talking about two different things though.

The v5 behavior I saw is this: setup a solo frame with 3 buttons, one each tied to scenes "A", "B" and "C". Place a cue-list outside the solo frame, and put scene "B" into its chaser. Then, toggle the button for scene "A" - note it becomes green/active. Now start the cue list, and note two things: 1) scene "B" also goes active, but its button does not turn green - it only turns yellow, indicating that it's associated function is running, but that it's not because someone clicked on that button; and 2) scene "A" stays green/active.

But then, if you toggle the button for scene "C" - note that scenes "A" and "B" stop and their associated buttons both turn "inactive". Or if you directly toggled the yellow button for scene "B" instead, scene "A" and it's associated button will stop and turn inactive (and the scene "B" button will change from yellow to green). So, if you directly toggle a Button in a soloframe, it definitely still behaves as a Master of sorts, and that's true whether it's toggled by mouse click or keyboard shortcut or external input or loopback magic. But if just the Function that's associated to a button in a soloframe starts, without having directly toggled the actual button, then it does NOT stop/inactivate any other active button in the same soloframe.

The difference is caused by just one line of code in qmlui/.../vcbutton.cpp having been commented out; quite some time ago it seems.

With this more specific scenario, do you still think it's behaving wrong? It feels right to me, but I'm a relative newbie here!

In v4, with that line of code active, note that it's impossible to put two Widgets into one soloframe that reference the same scene (i.e., in the example above, if that cue list was inside the soloframe, or if I had a collection that referenced scene "A" tied to another button in the soloframe). In these cases, if you start the chaser or collection, the chaser or collection's widget goes active, and then the button that references the scene directly goes to yellow/Monitoring state, and then immediately *both* widgets go inactive and nothing is left running.