Screen shots of the changes

Oh, and note in the screenshots above, I don't use the standard EOT character, which must've come from linux and looks horrible on MacOS. Instead, I use the MacOS double lozenge for EOT and <..> for missed frames. So the double lozenge in the screen shot is not a decoder error.

Even though I disagree with some of this, it is functionally well-done, and I find no functional problems with it. You're in control, I'm not, so do as you will...

73,
-Joe-
K0OG

Yeah, I looked that up and to be "politically correct" it does say to use 20 wpm instead of 20wpm. I'll fix that up :-)

It's just a UI thing. DIRECTED.TXT does not record mode speed at all. ALL.TXT records the mode speed, but using the definitions in JS8Submode, so JS8 6/160 is "C" and JS8 4/250 is "I". And JS Normal is "A" and Slow is "E", while Fast is "B".

Figure that one out :-)

Ok, fixed, rebased, force pushed. We got a space for them wpm's now!

Yeah, I looked that up and to be "politically correct" it does say to use 20 wpm instead of 20wpm. I'll fix that up :-)

It's proper grammar, lol!

It's just a UI thing. DIRECTED.TXT does not record mode speed at all. ALL.TXT records the mode speed, but using the definitions in JS8Submode, so JS8 6/160 is "C" and JS8 4/250 is "I". And JS Normal is "A" and Slow is "E", while Fast is "B".

Figure that one out :-)

Yeah, no idea how that came about, would have to ask Jordan, but to change it now would be considered a downstream breaking change.

One other consideration I had with this was that when the speeds are listed in the table in the UI, the column header is labeled "Speed" not "Mode". So instead of calling the two faster and less reliable modes JS8 6/160 and JS8 4/250 I considered using the approx wpm instead, which would make them JS8 40 and JS8 60. That would keep the Speed column more inline with what it is labeled as, so we'd have JS8 Slow, Normal, Fast, 40 and 60.

This would still use a different designation for the two more unreliable modes where HB is no longer allowed (which I should also note in the documentation). And stress that these two modes are separate and not necessarily weak signal modes that are suitable for MSG'ing et al. Try to get the point across better that they are faster QSO modes that are normally only going to be successful in good conditions.

This would be a fairly simple modification to this PR. It would address @Joe-K0OG concern that we are displaying more than 2 characters in the Speed column in Minimal Column Labels display mode. @rruchte what do you think?

@wmiler I pushed this change to rename the two faster modes JS8 40 and JS8 60, plus improved the documentation for them further.

Along with this PR I made some changes to the User Guide handling, as it also part of this UI change that I feel is necessary.

Main issue:
We are currently hosting different copies of the User Guide in five different places and none of these PDF's ever get updated except for the one on our website.

It changes the URL that the User Guide is displayed from in the JS8Call UI Help menu. It will display the markdown document from our code resources documentation workflow instead of PDF. This is a quite nice document with an index.

The reason for this is that I noticed updates were made to the User Guide, but it was never converted to PDF. So this ensures that the latest version is always displayed automatically, without anybody having to remember to update the PDF.

However, it does add a link in the markdown document to save an offline copy as PDF. This PDF comes from our github.io website downloads at https://js8call-improved.github.io/downloads/JS8Call_User_Guide.pdf

And also adds a link to the User Guide in the README.md

So this final change will eliminate having to host the User Guide in multiple places that forget to be updated, host it in one official place. And make it more accessible with the latest documentation for our users.

@Joe-K0OG I got to thinking about what you said. And you were correct. That Speed column is labeled "Speed" not "Mode". So I had created an inconsistency in the UI by displaying a Mode there instead of a Speed. So it made more sense to change the names of those modes to reflect the relative speed using wpm instead of a mode by frame time/bandwidth. And it fits nicely with the two-character limit in the Minimal Column Labels display mode.

I'll clean up the commit history on this and merge it.

Along with this PR I made some changes to the User Guide handling, as it also part of this UI change that I feel is necessary.

Main issue: We are currently hosting different copies of the User Guide in five different places and none of these PDF's ever get updated except for the one on our website.

It changes the URL that the User Guide is displayed from in the JS8Call UI Help menu. It will display the markdown document from our code resources documentation workflow instead of PDF. This is a quite nice document with an index.

So one issue with that, is that the Build Docs workflow follows master. So right now, there is a lot of 2.6 docs in it. So I'm not sure how we need to flag things in there as 2.6+ only items.

@Chris-AC9KH

This would be a fairly simple modification to this PR. It would address @Joe-K0OG concern that we are displaying more than 2 characters in the Speed column in Minimal Column Labels display mode. @rruchte what do you think?

I think that's fine. The column header has 2 chars. The inconsistencies in the mode naming and the labeling in this column offend my delicate sensibilities a bit but it is what it is, this is a good solution.

So one issue with that, is that the Build Docs workflow follows master. So right now, there is a lot of 2.6 docs in it. So I'm not sure how we need to flag things in there as 2.6+ only items.

I think that's actually pretty simple. Like the documentation I just added, I noted that JS8 40/60 appears in 2.6 and later. So somebody on 2.5 that's reading that will realize they don't have that feature until they get 2.6.0. This is not only good documentation that explains when new features were added, and at what software versions, it also provides a "preview" as to what's coming in future releases.

So from that standpoint I think it's actually better. I also think the User Guide could be versioned at something other than 2.2+. It could be versioned at 2.6 and earlier since there already is documentation in it for 2.6 that's noted that way, and it applies to all earlier versions otherwise.

So from that standpoint I think it's actually better. I also think the User Guide could be versioned at something other than 2.2+. It could be versioned at 2.6 and earlier since there already is documentation in it for 2.6 that's noted that way, and it applies to all earlier versions otherwise.

I've got some pending doc updates, I'll do that then. This can go ahead as is.

I've got some pending doc updates, I'll do that then. This can go ahead as is.

Yeah, there's some things in there that might yet need to be updated. Like Group Messaging that @rruchte did. I don't know if the User Guide has been updated for that yet. But if it hasn't, it needs to be done and add what software version that feature appeared in.

With the User Guide now in markdown, and it can be updated with any PR that adds a new feature. It is trivial to include updates that document the new feature along with a feature or enhancement PR. I didn't originally think markdown would be all that useful for the User Guide. But once I saw how it works with the documentation workflow it is pretty awesome for keeping it up-to-date, without somebody having to sit down and update it in one whack and is likely to only happen once every few years :-)