Indicator LED behavior of action buttons changed in version 2.9.3?

Since I'm new in this forum I'd like to show the background for my question. We have an old Taiwan drilling/milling machine upgraded with stepper motors and encoders on the axes. Axes motion and spindle (on/off, fwd/rev) are controlled by LinuxCNC 2.8.4 on Debian 10 using a Mesa 6i25 card. Later, some approaches adapting the GUI (AXIS) to fit the personal workflow had taken place. Quite soon the choice came to Qtvcp. Starting with the tutorial in the docs I set up a GUI according to my taste. For me it worked fine.

Now I want to switch to Debian bookworm using LinuxCNC 2.9.3 and, since I wanted to do minor extensions in the widgets, also want to have a development implementation cloning the git repository. The migration from 2.8.4 to  2.9.3 was basically not a big deal, only some conversion from python2 to python3 had to be done.

But, and that's my question, the behavior of the action buttons obviously has changed. The indicator LED of these buttons are only highlighted as long the buttons are not released (at switching on). The indicator function is referred to the status e.g. 'state_on'. The properties in the designer are set accordingly, i.e. 'indicator option', 'indicator_status_option' and 'is_on_status' e.g. are set to 'True'. The same behavior is observed in 2.10.0.pre (master c7b2655). I spent some time looking at the source code of action_button.py and indicatorMixIn.py. In the latter I came to the function 'connectSignals'   

def connectSignals(self):
        def _update(state):
            self.setChecked(state)
            if self._HAL_pin is False:
               self.indicator_update(state)
            # if using state labels option update the labels
            if self._state_text:
                self.setText(None)
            # if python commands call them
            if self._python_command:
                if state == None:
                    state = self._indicator_state
                self.python_command(state)

        if self.isCheckable():
            self.toggled[bool].connect(_update)
        else:
            self.pressed.connect(lambda: _update(True))
            self.released.connect(lambda: _update(False))
        _update(self.isChecked())

Obviously the indicator state gets set to False as soon as the button is released. Thus, the value previously set correctly by self._flip_state(..) gets overwritten. Shouldn't be the 'if'-statement, checking for the HAL-pin-option in the _update function also be extended to check for the status-option according to the _safecheck function in the action_button  code? Or do I mixing things with my very limited insight to the workflow of the code? At least, switching off the call of 'connectSignals' brings back the behavior known from 2.8.4.
Has anyone also observed this kind of behavior? And, just to mention, setting the button 'checkable' works as expected.

So you ate using a momentary push button with an indicator led?
You want the led to follow a HAL pin state?
Maybe you could show an image from designer so I can see all the properties you have set?
It's quite possible I broke behavior from 2.8, lots has changed.

Thanks for your answer. I want to use a Push Button (action_button) with an led indicator, yes. But the led should follow a LinuxCNC status such as 'machine_on' e.g., not a HAL pin status. I have attached a designer screenshot of the property settings.

I have also tracked the switching of the led when I click the action_button for switching the machine on/off:
action: set machine_on to: True
++ flip_state: mach_on: True
   indicator_update, mach_on: True
** _update from connected press/release signals mach_on state=False
   indicator_update, mach_on: False
The last update step obviously turns the led off again after it was set on by the _flip_state function. So I prevented the _update function in indicatorMixIn.py from calling the indicator_update function (the code change in blue color).  Thus, the led remains in true-state according to the current machine state.
 
       def _update(state):
            print(f"** _update from connected press/release signals {self.objectName()} state={state}")
            self.setChecked(state)
            if self._HAL_pin is False and self._ind_status is False:
                self.indicator_update(state)

Don't know whether it could cause unwanted side effects. As far as I could see it works in my context.
A second point: Some code in my handler file causes the logger in indicatorMixIn.py to become active. Obviously it was not set up in this module, so an error message was raised. Adding the corresponding lines to set up the logger fixed it.

First off - that was some great investigate work on this problem. That code is very complicated.

I see the problem you describe (even in master) and your proposed fix does seem to work.
I'll have to dig in a bit more to confirm nothing else will break.
Thank you for the report!

Chris

Ok I pushed your fix to 2.9 and master.
There was a race condition in 2.9 that made it hard for me to see the problem on my computer. Most of the time the led was right, sometimes it looked out of sync.

Could you show an image of your custom screen? I'm happy that Qtvcp was flexible and documented enough to convince you to try something unique.

Chris

Ok, fine! Sure I can. But it's a very light weight implementation. Only those features I need for my use case are implemented. Actually, most time I use the macrotab feature, even more than applying G-code (from FreeCAD).

Yes, I'm also happy that I tried to apply Qtvcp. It fits perfectly my needs and I was amazed how little code I had to write in my handler file.
Thanks a million for this excellent work!

Karin

Looks nice, clean and uncomplicated! Thanks for showing it.