Skip to content

Conversation

@df7cb
Copy link
Contributor

@df7cb df7cb commented Nov 22, 2025

There is little point in delaying startup when there are no "interesting" messages. Remove sleep(1); the user can still request a verbose run with tlf -v (this is the default on the first startup anyway).

When having to restart tlf during a contest (after changing some setting for example), that second actually makes a difference.

There is little point in delaying startup when there are no
"interesting" messages. Remove sleep(1); the user can still request a
verbose run with `tlf -v` (this is the default on the first startup
anyway).

When having to restart tlf during a contest (after changing some setting
for example), that second actually makes a difference.
@dl1jbe
Copy link
Member

dl1jbe commented Nov 23, 2025

There is little point in delaying startup when there are no "interesting" messages. Remove sleep(1); the user can still request a verbose run with tlf -v (this is the default on the first startup anyway).

When having to restart tlf during a contest (after changing some setting for example), that second actually makes a difference.

Understandable and a good reason.

Question is if we should drop the display of the startup completely if 'verbose' is not set.

@df7cb
Copy link
Contributor Author

df7cb commented Nov 23, 2025

Maybe the startup messages could go to the area in the top left where the CW messages are printed? That would also be a good place for error messages during operation.

There are various annoying delays associated with error messages like "unable to send cw" that currently go to the bottom line where the purpose is (I think) to make sure the next message doesn't immediately overwrite the message. If these messages would instead go to a scrollable area, there would be no need for delays.

@zcsahok
Copy link
Member

zcsahok commented Nov 24, 2025

Apart from removing the final 1 sec delay I would keep messages as-is for the time being until we come up with an alternative display, a bit like :INF.
This change will be then not only about the messages themselves, but could lead to a redesign of some internals.

Example: start with rig control via rigctld, but the rig is off.
With messages on one gets

Rig model number is 2
Rig speed is 2400
Trying to start rig control

and then wait.... and finally

Continue without rig control Y/(N)?

Without messages one currently would just get a black screen until operation times out.

not related this this PR: other annoying stuff is the cluster login ("...not dead..."), this is on my shortlist.

@dl1jbe
Copy link
Member

dl1jbe commented Nov 24, 2025

Yes, for the time being it is ok. In the long run a direct start to the main screen with progress and error messages displayed there would be fine.

Taking the comments as approval, let us merge it in.

@dl1jbe dl1jbe merged commit e0e5c77 into Tlf:master Nov 24, 2025
2 checks passed
@df7cb df7cb deleted the start-fast branch November 24, 2025 12:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants