move Halui into task by rene-dev · Pull Request #4644 · LinuxCNC/linuxcnc

rene-dev · 2026-10-06T12:46:42Z

there is really no reason for halui to be its own process, and go thru nml - it is much better to be integrated in task.
this is the next step to fully remove nml, the only place it is left now is the ui <-> task communication.

grandixximo

This is a good move: halui in task removes a whole process and its NML round trip with no behavior change, and the new tests/halui suite pinning down the quirks is exactly what a port like this needs. I support merging it.

One question on the config sweep: did these get missed, or was leaving them deliberate? They still set HALUI = halui:

configs/sim/axis/db_demo/base.inc (pulled in via #INCLUDE by db_nonran.ini and db_ran.ini)
configs/sim/axis/ja_tests/xz/xzbase.inc
configs/sim/tklinuxcnc/trivkins/xzbase.inc
configs/sim/touchy/ngcgui/pyngcgui_touchy_moveoff_es.txt

Harmless now that the setting is ignored, but they will confuse anyone grepping for how halui gets started.

The rest is inline.

grandixximo · 2026-10-07T09:38:30Z

+*   state gating, same serial-number echo, same error reporting.
+*
+*   Two producers use it:
+*     - ws_server.cc, from the websocket server thread


ws_server.cc does not exist anywhere in this tree. Is the websocket server a planned follow-up? As written, "Two producers use it" reads like there is a second producer today, but halui.cc is the only one.

grandixximo · 2026-10-07T09:38:30Z

 #include "motion/motion.h"             // EMCMOT_ORIENT_*
 #include "ini/inihal.hh"
+#include "halui.hh"		// the HAL user interface, in task
+#include "cmd_queue.hh"		// commands from ws_server and halui


Same question as in cmd_queue.hh: ws_server is not in the tree, so what does "commands from ws_server and halui" refer to?

grandixximo · 2026-10-07T09:38:30Z

 	$(Q)$(CXX) -o $@ $(ULFLAGS) $^ -lfmt $(LDFLAGS)
 TARGETS += ../bin/linuxcnclcd
-
-../bin/halui: $(call TOOBJS, $(HALUISRCS)) ../lib/liblinuxcnc.a ../lib/liblinuxcncini.so.1 ../lib/libnml.so.0 ../lib/liblinuxcnchal.so.0 ../lib/libtooldata.so.0


Removing bin/halui breaks user configs that start it from a HAL file with loadusr halui -ini ..., which is the pattern the docs recommended for StepConf-generated configs, so it will exist in real user setups. The [HAL]HALUI = form degrades gracefully since the pins now always exist, but the loadusr form is a hard startup failure. Would a no-op halui shim be worth keeping for one release? It could print a warning that the pins are built into task now, so those users learn about the change instead of silently succeeding. At minimum I think this needs a migration note in the docs.

grandixximo · 2026-10-07T09:38:30Z

-  the nml file specified in the INI, usually that file is in the same
-  folder as the INI, so it makes sense to run halui from that folder.
+The pins are part of the LinuxCNC task controller and exist in every
+configuration. There is nothing to load and nothing to configure: connect


Is "nothing to configure" quite right? [HALUI]MDI_COMMAND, [DISPLAY]MAX_FEED_OVERRIDE and the spindle override limits still configure halui. Maybe just "nothing to load"?

grandixximo · 2026-10-07T09:38:31Z

----
+There is nothing to set up: the pins exist in every configuration, created
+by the task controller before the HAL files are read, so a HAL file can
+connect them straight away. Pins nobody connects cost nothing.


Does this agree with the halui.cc header comment? There you write that a machine connecting none of the pins still pays for a pin scan every 20 ms. Negligible either way, but which one is it?

grandixximo · 2026-10-12T06:23:32Z

@rene-dev I still support this. @c-morley raised a point on #4613 that I think this PR should answer, though:

Right now if you don't like the way HALUI works or assumptions it makes you can write a substitute program (for example panelui) that make different choices and assumptions. [...] Once you put HALUI into task the you are much more stuck with those choices.

As I understand it, the pluggability stays as long as halui inside task has no privileges a client does not have. A substitute like panelui would then be a client of the new interface, and it should be able to do everything halui does:

send the same commands, through the same path in task;
read and set the operating state halui holds today (jog rate, selected axis, increment), which with this PR lives in task, so the GUIs can share it instead of keeping their own copies;
get completion and errors for its own commands.

Is that the plan? If so, I think it is worth stating here and on #4571, so the move is not read as closing the door Chris is worried about.

rene-dev · 2026-10-12T08:39:26Z

I haven't removed the ability to do this, and in fact you can still use the old halui code with this changes. The interface is exactly the same. But you will face all the same problems. The same problems halui has. I haven't looked at panelui, need to see what that is about.

grandixximo · 2026-10-12T08:51:42Z

@rene-dev panelui is Chris's alternative to halui: an INI-configured operator panel with its own button logic and a Python handler (docs, code, demo config). It talks to task through the linuxcnc module, so over NML.

"You will face all the same problems" is my concern. Moving halui into task fixes them for halui only; every other client keeps them. I am fine with the move as a step, but I would like it tied to a commitment to fix the problems, not only to relocate them:

the quirks the new tests/halui suite pins down: which of them are bugs, and is there an issue to fix each one rather than keep it pinned?
with the NML replacement, any client gets completion and errors for its own commands, so panelui or a GUI is not worse off than halui inside task;
the operating state halui holds (jog rate, selected axis, increment) can be read and set through the same interface, so halui and the GUIs stop keeping separate copies; that is the bug Zmq halui gui #4613 was working around.

Could you note that in the PR description or on #4571, so the follow-up is on record?

Drop references to a websocket server that is not in the tree, list the INI settings halui still reads, and state the cost of unused pins consistently.

Configurations that still run 'loadusr halui' would fail to start now that the program is gone. Install a halui stub that prints a warning and exits successfully, warn at startup when [HAL]HALUI is set, and add a migration note to the update docs.

They pinned down halui's behaviour so the move into task could be checked for changes. That is done; the pre-existing halui/jogging and halui/mdi tests stay.

rene-dev · 2026-10-16T10:44:59Z

I have addressed all the comments, including a stub which can be removed later.
I am fully aware that this is not the ideal solution, but it is something to build on in moving more state to task, and removing nml. It was designed on purpose not to change behavior in this step, that will be a separate PR.
the main thing is to remove multiple UIs, as this is something NML cannot deal with.

panelui

panelui works exactly as before, and if more state moves to task, panelui can drive these pins via hal to gain all its advantages, or use the new UI api when that is ready.

UIs pins

work exactly as before, and if more state moved to task in the next PR, they can also take advantage of those pins, and their own versions of the pins can be removed.

grandixximo reviewed Oct 7, 2026

View reviewed changes

rene-dev added 6 commits October 16, 2026 10:47

add halui tests

606313a

remove halui from example configs

cb04d86

remove halui from test configs

fb2ddb5

move halui to task

99b5140

remove halui from ci

bdf222d

fix halui tests

02f1522

rene-dev force-pushed the halui-task branch from 25a546f to 02f1522 Compare October 16, 2026 08:48

rene-dev added 4 commits October 16, 2026 11:12

remove remaining HALUI settings from configs and tests

3c5ccb0

halui: fix comments and docs

235032b

Drop references to a websocket server that is not in the tree, list the INI settings halui still reads, and state the cost of unused pins consistently.

tests: remove the halui move verification tests

77a491f

They pinned down halui's behaviour so the move into task could be checked for changes. That is done; the pre-existing halui/jogging and halui/mdi tests stay.

rene-dev marked this pull request as ready for review October 16, 2026 10:58

Navigation Menu

Repository navigation

move Halui into task - #4644

move Halui into task#4644
rene-dev wants to merge 10 commits into
LinuxCNC:masterfrom
rene-dev:halui-task

rene-dev commented Oct 6, 2026

Uh oh!

grandixximo left a comment

Uh oh!

grandixximo Oct 7, 2026

Uh oh!

grandixximo Oct 7, 2026

Uh oh!

grandixximo Oct 7, 2026

Uh oh!

grandixximo Oct 7, 2026

Uh oh!

grandixximo Oct 7, 2026

Uh oh!

grandixximo commented Oct 12, 2026

Uh oh!

rene-dev commented Oct 12, 2026

Uh oh!

grandixximo commented Oct 12, 2026

Uh oh!

rene-dev commented Oct 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

rene-dev commented Oct 6, 2026

Uh oh!

grandixximo left a comment

Choose a reason for hiding this comment

Uh oh!

grandixximo Oct 7, 2026

Choose a reason for hiding this comment

Uh oh!

grandixximo Oct 7, 2026

Choose a reason for hiding this comment

Uh oh!

grandixximo Oct 7, 2026

Choose a reason for hiding this comment

Uh oh!

grandixximo Oct 7, 2026

Choose a reason for hiding this comment

Uh oh!

grandixximo Oct 7, 2026

Choose a reason for hiding this comment

Uh oh!

grandixximo commented Oct 12, 2026

Uh oh!

rene-dev commented Oct 12, 2026

Uh oh!

grandixximo commented Oct 12, 2026

Uh oh!

rene-dev commented Oct 16, 2026

panelui

UIs pins

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants