Please remove annoying pop up window about help messages

[dagewa]

When dui2 starts this pop up appears in front of the DUI2 window

What is the point of this? The user does not need to know this information, and can't do anything about it. Just don't show it.

[ndevenish]

Is it the client or the server emitting this? The client as I understand it should never be doing this (only the server has DIALS), and the server should never be launching a UI????

[luisodls]

When running separately client and server with two processes the client asks for the help texts to the server by get requests and shows progress on the client side.

When running all in a single process (the default mode) the 95% or more of the code is reused. The code is still separated and named differently as if they where different processes but they are wired differently. in a way that they interchange variables directly. Without a need for any of the requests . In this case talking about client or server makes less sense.

[dagewa]

Either way, I don't think it helps the user at all to see this message.

[ndevenish]

That sounds.. confusing. And even if it were necessary (I am not convinced, same-process client-server should be lightning fast, let along IP/in-process alternatives), it shouldn't be necessary for this job where the actual work (running all the dials tools to introspect) is >> communication time.

Where does this dialog originate? Have you written the code to do this twice, in two different places, or is it the server showing this?

[ndevenish]

Maybe this response from claude is a bit clearer about where my concerns are coming from

Seeing a "Getting help for command" popup on client start. This seems like something the server should be handling? Please find out why and when this is shown and the implications about server structure client/server configuration because of it.

Why this is a client/server concern

You're right that this feels like server-side work — and it largely is server-side work. The actual help text extraction (get_help_list in data_n_json.py) runs on the server via importlib.import_module and subprocess fallbacks. But the orchestration happens on the client:

1. The client drives the loop — HelpRequest.run() iterates over all ~50 commands, making one HTTP request per command (get_req_json_dat sends requests to the server's REST API).
2. The result is stored client-side — dials_help_ended() stores the dict as self.help_msg_dict on the MainObject.
3. The popup is a client-side QDialog showing progress for each individual round-trip.

This means ~50 sequential HTTP requests are made at startup just to collect help strings. This is chatty — a single server endpoint that returns all help texts at once would eliminate the popup entirely and speed up startup significantly.

Implications

• Startup delay: The client blocks on ~50 serial network round-trips before the help data is ready. The 2-second QTimer delay is a band-aid so the window appears first.
• Tight coupling: The list of commands is hardcoded in the client (exec_utils.py:656-707). If the server adds/removes a DIALS command, the client needs updating.
• The server already knows all the commands — it could expose a single get_all_help endpoint, return the full dict, and the client wouldn't need the loop, the thread, or the popup at all.
• ProgressBox is acknowledged as misplaced — see the comment at q_object.py:69: #FIXME: ProgressBox belongs elsewhere.

[ndevenish]

Unless it's wrong, I am also a little concerned about the over-reliance on Timers for getting everything to happen in the right order?