ProffieOS Documentation (POD)

I just tested creating edits for non-collaborators.
It’s actually really easy. You would need a github account of course.
First time you try to edit something, it says it will create a fork for you.
Once the edit is done, it saves it in a branch on your fork, and then it asks if you want to create a pull request. Once the pull request is done, I get an email, approve or disapprove the change, and that’s it.

All of this happens on the github site, so it’s just a few extra clicks compared to being a collaborator.

This is mostly how I do all my pull requests.

I also added a POD page for how to make edits. Feel free to improve. :slight_smile:

Things are coming along.
Most of the pages are now organize in directories, which should make it easier to find stuff.
It also makes the all pages page fairly well organize.
I’ve also added an everything on one page, page, but it might need some more work to be useful. If nothing else, it makes it possible to find stuff without knowing what page it’s on. It could also be printed to a PDF and saved, or even printed out, if someone feels like there are too many trees on the planet…

At some point I should probably spend more time writing documentation and less time making it nifty though. :slight_smile:

3 Likes

Looks like I broke some links while re-organizing the docs.
Should be fixed now.

I guess I need to finally register in Github, and see if I can help contribute to the docs. I will re-direct links to the POD!

It’s quite easy, and you don’t need to know anything about git.
I even wrote a page about it:

I really should work making the “link descriptions” better somehow though.

Writing documentation is more fun now that most of the wiki issues have been resolved, some new pages:

2 Likes

It needs some CSS to make it look pretty, but I added a search box.

Search box addition is huge! Thank you.

Could we have a page explaining how to use FromFileStyle ?
and videotoblc.
I did it once, and while it was quite the process, I feel there’s a lot of possible untapped power there for blade effects.

If you don’t want to write it, yourself then file an ‘issue’:

Fixed all broken links but 1, which i think is some weird phantom.

bconner@BCmini:~\🖖 $ wget --spider -r -nd -nv -l 3  https://pod.hubbe.net/ 2>&1 | grep -B1 'broken link'

https://pod.hubbe.net/%22+results[i].ref%20+%20%22:
Remote file does not exist -- broken link!!!
Found 1 broken link.

Actually, it’s coming from here, but I’m not sure what’s the problem.

I think wget ends up parsing the javascript for some reason.
Seems like a bug in wget.

So far only one drawback of the new format. We used to be able to get a link directly to the sub-section of a page to point someone to the correct thing to read, such as jumping right to #style-definition:

The anchors are still there, but there isn’t an easy way to “get” the links right now.
I did experiment with this thing called jekyll-linkify, which puts a “#” mark next to every heading, but I thought it looked kind of ugly. Also, it’s written entirely in jekyll, and while I’m not sure I think it might break some things.

In the original wiki, the link thingy only shows up when you hover over the header, which is a neat trick. We should probably try to do something like that. Either with jekyll-linkify, or maybe we can do it with pure CSS.

One option for the technically savvy user is to use right click → inspect, which will the element and it’s ID (which can be used as an anchor).

This is the way

I’ll see if I can get this in there this weekend.

Ok, now when you hover over a header, a # appears, and you can click on it or use “get link address” on it.

Unfortunately it seems to be sort of broken for headers which are also links.

Actually, maybe it’s not broken, it’s just that the anchor names are weird.

I tried using a unicode link symbol instead of #, but I’m not sure if I like it.