add FKEY-HEADER

[zcsahok]

Sequel to #229 by @ha5se

• removed unused variables k_tune from main and the externs from clear_display.

[dl1jbe]

I had done it in show_header_line, but that is another way. Fine.

[zcsahok]

This way it's done once at start. All else stays as-is.
When we'll have variable width, then we can re-think this and probably other stuff as well.

[ha5se]

• Imho, centering would possibly be better off in parse_logcfg, needed only once per config-file re-read
• just because the next idea is almost completely implemented by now, needing only to conditionally zero out left- or right padding, would it be too much Left|Centered|Right aligning instead of centering, FKEY_HEADER=[L:|C:|R:]text, defaulting to "C:" ?

[zcsahok]

Centering will be just a nice to have once we implement leading/trailing whitespace for config values. This is on my list. With whitespace the user will have better control on the appearance of the text.

[ha5se]

Thank you very much, fully agree on whitespaces with you.

[ha5se]

removed unused variables k_tune from main

good hit again, it is a leftover by mistake when I split my two new keywords into two branches...

[ha5se]

On 29/01/2021 07.10, Thomas Beierlein wrote: ***@***.**** commented on this pull request. ------------------------------------------------------------------------ In test/data.c <#232 (comment)>: > @@ -196,6 +196,9 @@ char message[25][80] = /**< Array of CW/DigiMode messages "", "", "", "", "", "", "", "", "", "", "" }; +char fkey_header[60] = + " 1=CQ 2=DE 3=RST 4=73 5=HIS 6=MY 7=B4 8=AGN 9=? "; + Sorry, I do not agree here. Even if its broken does not mean we should make the situation worse. We should either make it right here or if :CFG is sooo bad - than we should just drop or block it completely.

Well, I second to Thomas, I wish we could at least keep existing functionality. My limited experience is rather positive with :CFG. I think simple definitions are working OK, I repeatedly adjusted F-key-definitions without restarting. I assume even contest definitions could be somewhat adjusted on the fly. On the other hand, I can hardly imagine if I ever wanted to replace the rig during a contest. (would be hard for me anyway, possessing only a single tcvr ;-) ). It would be time-consuming anyway -- would need replacing cables, so not much additional time-penalty from re-starting the logger...

[zcsahok]

Added code to center after :CFG.

For the :XXX related issues incl. config reloading see #233.

Personally, I would not apply my last commit.

[dl1jbe]

I see no need to rush to a quick solution.

I can understand your motivation to just keep the hands off the :CFG problem for now.
Let me just explain the reason for me disagreeing:

• FKEY_HEADER is a feature users will likely use more than once. When it behaves weird, they will complain and send bug report to handle - more work for us. And they will not wait till we iron any problems out and prepare a new release. In the days of github they often use the development branch and build from there.
• Other features are still wrong -right- but they seem to be seldom used (or the users are common with the problem).

So not introducing 'weird behavior' means less work for us fixing problems/explaning why it is how made it and more time for going forward.

Thus said I see some solutions for the problem:

1. Fix :CFG behavior. I fear that is not doable in short time, so that seems not really to be a solution.
2. Drop centering the line completely. Just print it left (or right). As soon as your planned 'Keywords with spaces' feature is available the user has enough control over the appearance of his text. Until then the behavior is at least consistent.
3. Fall back to center it during show_header_line

What do you think?

[zcsahok]

I don't quite get what is still outstanding as the last commit fixes centering after :CFG. At least for me it works.

[dl1jbe]

There was nothing wrong with your commit. I just wanted to say, that there are other ways to avoid the reformating after :CFG as you are not happy with it.