ReadMe Viewer is VERY BROKEN

[Moire9]

As the title says, the ReadMe viewer is very broken. Since the ReadMe is MD, it will show all the _'s and `'s and *'s that you would not normally see. This makes it a bit harder to read. But, the most important problem is that when you press down, it jumps to the next section instead of going down. This makes it impossible to read most of long sections. For example, if I wanted to read the lengthy Write Permissions System part, it would be impossible to read about the Red and Blue, since the screen will not fit that much, but pressing down will jump directly to the Support Files section, which is also too long making it impossible to read. Please allow us to actually scroll, perhaps assign section-jumping to the left and right buttons on the DPAD?

About the first issue I mentioned, I have provided a modified ReadMe.md (okay, well, GitHub doesn't handle md files, so it's README.txt–rename it to ReadMe.md) that will work with the ReadMe viewer. Also, you neglected to add information about the [K:] AESKEYDB IMAGE drive, so I added that in there.

Also, something completely unrelated, in the ReadMe it said that on sighaxed systems I would have access to the otp.bin, boot11.bin, and boot9.bin in the [M:] MEMORY VIRTUAL drive. Currently I am running from the Bootloader, but my system WAS sighaxed, but these files were never there. Don't know why not, it's not really that important to me, just thought I would point that out.

Also, my self-compiled version of GodMode9 is missing the Show ReadMe option in Home -> More.. for some reason. I tested release 1.4.3 and it shows up. I don't know why.

And that's it for now. I don't really know how to end this, so I'll say Have a Good Day!

[windows-server-2003]

About the first one : For now, the README viewer doesn't have the ability to interpret MD. @d0k3 may add MD support.

About the second one : Press A ! It will enter to the standard text viewer and you can scroll anywere. @d0k3 It should return to the main menu of README viewer when the B button is pressed on the detailed README viewer mode. Currently, it returns to the file explorer and not useful.

About the 3nd one : "via boot9strap" is missing maybe. You can't access to such location if you are not using B9S.

About the final one Is there a README.md in the "data" dir in the source dir ?

[d0k3]

Oh well...

@windows-server-2003 - GM9 will never have the capabilities to correctly format .md files, that's some pretty advanced stuff.

@SirNapkin1334 - we want a properly formatted readme here on GitHub, and we want one that's human readable in it's text form. Markdown is the way to go here, and there's no way we'll keep two versions of the readme. With a compromise such as this, it's pretty clear that not everything can be 100% perfect, but it's still perfectly readable.

Also, you noticed, you have to press A. The coloring of the chapter title on the bottom screen is subtle hint that you are inside a selection menu right now. I may gray out the text on top to make that even more clear - thinking about it.

otp.mem is available from the bootloader, boot9.bin and boot11.bin is only available from b9s.

I took over some of the readme fixes you suggested locally. Also, when compiling, use the newest commit.

[Moire9]

You could hardcode the "fixed" ReadMe.txt so it will read that instead. I suppose that would be a bit difficult to maintain two at the same time, but really all you have to do is use a text editor to replace all the #, _, !, :, and ` with nothing, and remove the links. A better solution would be to simply not change the hardcoded one until the next release, instead of having to change it whenever you change the regular ReadMe.md

Also, you still neglected to add information about the K: drive, so I'll give you what I had written. [K:] AESKEYDB IMAGE: An aeskeydb.bin can be mounted and accessed via this drive. It shows all keys inside the aeskeydb.bin. This is read-only.

[Nemris]

@d0k3

I was just about to open a new issue myself, when I noticed this one.

It's not only a matter of leftover MarkDown and links in GM9's ReadMe, but also a matter of still present developer-oriented paragraphs, such as "How to build this" that, in my humble opinion, has no place in a built-in program manual for end users.

If you don't want to maintain two separate ReadMes yourself but are open to someone else keeping tabs with the second, I'm up for the task.

[d0k3]

Well, I don't like the idea of maintaining two READMEs. Also, as I already wrote, markdown is designed to be readable in it's raw state, too. Also. remember that some of these markups are required so that we can provide navigation to the README file.

If you really want to maintain a second, more minimal readme, you know that this won't be a one time task. A new release is coming up, with it some edits to the readme, and there will be more in the future. With no auto-creation during build possible, it's almost a given that second readme will fall behind, and one condition would be that it would never fall behind by too much.

Maintaining then would mean you should try to automate some stuff on your side, and also don't wait too long for updates to the readme. Also, the minimal readme would need to stay in basic markdown format, meaning that section titles would have to be formatted the same way as they are now and incompatible sequences would not be allowed. Also, any possible improvements (fixing typos, clarification) to the readme you do would have to go into the main readme first, minimal readme second, so that both stay in sync.

[Nemris]

@d0k3 That the final decision rests upon you is a fact.

I'm aware that this will be a task that perdures for the entirety of the project's lifetime and that some MarkDown (e.g. headers) is used by GM9 to build things such as the table of contents, while others, such as bullet points, are required for readability. Still, I hold that the manual's current state seems unpolished to me, not reflecting the same amount of care the code itself saw.

Automating this shouldn't be too problematic; throwing up some Python-based decluttering script will do the job, alongside a hefty amount of testing. Fetching and feeding the ReadMe to said script would be done by me, but that shouldn't be an issue, as I check the repo at least once per day.

Regarding what would be modified, aside from scrubbing unneccessary MarkDown and links, and dropping the "Developer info" paragraph, I don't plan to mess with the ReadMe further, so that it'll reflect the one available here for the most part.

[d0k3]

Alright, I'm okay with it. Still unsure if the modified readme should go into the data dir or into the resources dir. We'll decide later. In any case, the modified readme should still be proper markdown (you can remove links and stuff, of course). Just send me a pull request once you're ready.

[Nemris]

@d0k3 Got it. One last thing: is it unreasonable to ask for a special test build of GM9 that loads whatever file it finds at a fixed path as the ReadMe? Would be helpful in testing that nothing gets borked.

[d0k3]

That requires more changes than you may think... Can't you compile GM9? If so, just use A9NC and either fb3ds or GM9 as bootloader. The effort requiered isn't really more than the effort of just replacing the readme file.

[Nemris]

@d0k3 Unfortunately, I'm in no position to fetch the required tools, as my computer is permanently offline. Every time I code, I do so from Android.

Still, I already figured out which syntax to leave untouched, and am currently working on a piece of code to automate the scrubbing procedure. No ETA, obviously, but I'll let you know when I have something in an usable state.

Update: I'm now able to unpack and repack GodMode9.firm thanks to some firmtool black magic. Testing can begin.

[Nemris]

@d0k3 The ReadMe to be baked in is in an usable state; now thinking whether to replace the backticks with regular apostrophes. Did you reach a decision about where to put the file?

[d0k3]

Nah, just leave the backticks, I guess. Unless there's some good reason not to. Put it in the data directory. There are also some changes requried to the Makefile, but you can leave that to me.

[Nemris]

@d0k3 Pull request incoming. If you're interested, I can also share the Python tool I coded for the occasion.

[d0k3]

Only if it's self contained and fully automated (= needs no manual edits to the readme). In that case we could also add it to the build process.

[Nemris]

@d0k3 It's "batteries included", so no outside libs required.

Manually editing the ReadMe isn't required, but the tool will look for a patch.json.gz file located in the same path as the .py itself. This file is a database of patterns to look for in the ReadMe, and allows for targeted modifications, such as the deletion of whole paragraphs.

Basically, the patch.json.gz file is the only thing you'll need to modify, if you want to replace something in the ReadMe.

[d0k3]

You still need to manually remove that paragraph, right? Anyways, better to continue that dicussion in the pull request. If we can fully automate the readme edits, we should. If not, I'll better leave that in your hands.