gmoccapy: modal startup "Important change(s)" dialog blocks headless / non-interactive startup

[grandixximo]

gmoccapy's _startup_message() (src/emc/usr_intf/gmoccapy/gmoccapy.py:544)
pops a MODAL "Important change(s)" release-notes dialog during __init__ via
dialogs.show_user_message() -> Gtk.Dialog.run(), whenever the preference
hide_startup_messsage is less than the number of release-note messages.

The preference file is created at runtime with hide_startup_messsage = 0,
so on a fresh profile the dialog always shows. Because Gtk.Dialog.run() spins
its own nested main loop, the gmoccapy constructor never returns until a user
clicks the dialog. Under a headless / non-interactive launch (xvfb, CI, the
ui-smoke tests in PR #4054) nobody dismisses it, so gmoccapy hangs at startup.

Reproduce:

• Remove or reset the config's gmoccapy.pref (so hide_startup_messsage = 0).
• Launch the gmoccapy sim under xvfb.
• py-spy on the gmoccapy process shows it stuck in:
  run (gi/overrides/Gtk.py)
  show_user_message (gmoccapy/dialogs.py)
  _startup_message (gmoccapy.py:560)
  init (gmoccapy.py:506)

Impact:

• Any automated / headless launch of gmoccapy with a fresh profile blocks.
• The ui-smoke gmoccapy test must pre-seed or auto-dismiss this dialog.

Possible fixes (for discussion):

• Skip the startup dialog when running non-interactively (e.g. detect no
  interactive display, an env var, or a CLI flag).
• Make the dialog non-modal / auto-timeout.
• Show the notice via the in-app notification area instead of a blocking dialog.

[hansu]

I can move the important changes information to the non-modal gmoccapy message pop up like this.
I only have to extend the gmoccapy notification class to allow check boxes.

[grandixximo]

Leaving this in your hands then ;-)

[hansu]

Please try if it works for the smoke tests with this draft: master...hansu:linuxcnc:gmoccapy-changes-as-notification

[grandixximo]

Tested your draft against the ui-smoke gmoccapy config (applied just the gmoccapy.py + notification.py changes on top of current master, uspace RIP under xvfb).

It fixes the headless block. py-spy on the gmoccapy process:

• master: stuck in dialog.run() (_startup_message -> __init__), so the constructor never returns and Gtk.main() is never reached.
• your branch: sitting in Gtk.main() at module level, i.e. fully constructed.

Worth noting: the phase-1 smoke test reports UI_SMOKE_OK either way, because it only checks that the NML task is reachable, not that the GUI finished constructing. So that test does not catch this on its own; the stack dump is the evidence. No tracebacks from the notification path at startup.

One note, which you already flagged: the hide-message/checkbox logic is commented out in the WIP, so the notification shows on every start for now. Once the checkbox is wired into the notification class that is covered.

Thanks for picking this up.

Follow-up: I also ran the phase-2 g-code smoke test (run smoke.ngc, check the endpoint delta) against both versions. Same result, UI_SMOKE_OK on master and on your branch. Phase 2 drives estop-reset / home / run / endpoint-check entirely through NML to the task, which is alive whether or not the GUI finished constructing, so it does not catch the block either. Your change passes both phases.

[hansu]

Ok great, then I can continue and add the checkbox :)