Unify the way MDI commands are executed from HAL / GUI

[zz912]

Background

There are currently several ways to start an MDI command in LinuxCNC. This can lead to different behavior depending on how the command was triggered and how the particular GUI handles the resulting mode changes.

I originally opened PR #3441 to address a specific problem in Gmoccapy. When a halui MDI command is executed, LinuxCNC temporarily switches to MDI mode and then returns to the previous mode:

Original mode → MDI → Original mode

For short commands, this can happen so quickly that the GUI may only briefly switch to the MDI page. In Gmoccapy, I have also seen cases where the rapid sequence of mode changes can result in GUI elements remaining disabled when they should not be.

I don't think that making this screen change less visible, or simply preventing the GUI from switching pages, is the right long-term solution.

One mechanism for MDI commands

I would prefer LinuxCNC to have one common mechanism for creating/executing MDI commands, rather than maintaining several parallel mechanisms with different behavior.

This was already discussed in PR #3580. I wrote:

"I would like to have only one way to create macros."

HansU replied:

"Agree."

PR #3580 then explored using communication between HALUI and the GUI, with the GUI being responsible for executing the INI-defined MDI command. The idea was interesting because it also allows the GUI to decide how it should react to the command, instead of reacting afterwards to mode changes initiated elsewhere.

The particular implementation of #3580 was later reverted, so I don't want to prescribe that implementation here. The architectural question, however, still seems relevant to me.

What I would like to achieve

I would like to see a common way of handling MDI commands which:

• provides the same basic behavior for all GUIs;
• avoids unnecessary Original → MDI → Original GUI page switching;
• gives the GUI enough information to provide an appropriate indication that an MDI command is running;
• provides a consistent way to abort a running command;

The exact implementation should be decided separately. This issue is intentionally not proposing a specific implementation.

Why I am closing PR #3441

PR #3441 addresses a real problem, but I no longer think that its Gmoccapy-specific implementation should be merged as the final solution.

The problem is more general than Gmoccapy, and I think it would be better to solve it at the appropriate level so that all GUIs can benefit from the same behavior.

For that reason, I am closing #3441 in favor of this issue rather than continuing to modify Gmoccapy around the current MDI mechanism.

Current situation

I also think it makes sense to wait before implementing another solution here.

Chris has been working on the HALUI ↔ GUI communication using ZMQ. I don't understand the ZMQ implementation well enough to judge what the final architecture should look like, and I don't want to introduce another solution in parallel while that work is still evolving.

My preference is therefore to keep this issue as a record of the problem and the desired direction, and first see where the work on the HALUI/GUI communication leads.

Once that direction is clear, this issue can be revisited and the appropriate solution can be implemented at a level that is useful for all GUIs, rather than adding another Gmoccapy-specific workaround.

[gmoccapy]

@zz912

if I understand the problem correctly, the "race condition" is caused only if the MDI command is executed from Halui commands.

That is why I am asking myself, should an MDI command be handled through halui, or is an MDI command in the responsibility of the GUI?

IMHO halui is not the correct way to handle halui commands. A lot of problems we solved on gmoccapy was caused by mixing Halui stuff and GUI related parts.

I would suggest a way, where a GUI does get an information if an halui MDI command should be run, as this way the GUI may avoid mode switches

I am open for more discussion.

[zz912]

I think that, technically, it should be possible to make several different architectures work reliably and without bugs. However, I don't want to get involved in the discussion about which architecture would be better for us. I have done that in the past, and in the end I think I only added confusion to the discussion.

So I can discuss LinuxCNC only from the perspective of a tester, user, and integrator. Personally, I don't want to advocate either HALUI MDI commands or GUI MDI commands.

What I would like to advocate for, though, is that there should not be two different ways of doing the same thing, each with different behavior or different problems. I think we should look for a solution that is consistent and reliable from the user's point of view, regardless of which architecture is used internally.

Are you familiar with Chris's work with ZMQ? #3580 If I understand it correctly, he has actually created a third approach: halui.gui.mdi-command.

Here, I have proposed a new type of macro from the perspective of the user and the integrator:
#3580 (comment)
What do you think about it?