New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vacation PR: multi-paged, styled, searchable docs with wrapper tooling and epubs for NixOS and Nixpkgs #68020
Conversation
manpages no longer exists on manual attr set: nixpkgs/nixos/modules/misc/documentation.nix Line 194 in be8bd43
I only see manual, manualHTML, manualHTMLShell nixpkgs/nixos/doc/manual/module.nix Line 41 in be8bd43
|
Will this break all of the current URLs that refer to the anchors on the single page? |
Yes, as it is. I think we could work out a solution, literally thinking of it as I type.
The main issue there could be is history hijacking. It may be possible to do something tricky with html5 history, and window.reload, to overwrite the one entry. Tasks
|
It might be possible, but it will cause issues with narrower layouts, especially with sections having longer titles. There is another issue with the UX where the current implementation presents a clear separation of the search mode and the documentation consultation mode. And additionally, while it looks like there is only a search box, there are elements in the search overlay that are currently unlikely to be seen. Among those is the loading state of the index. If we want to add more options to the search engine we would be furthermore constrained in space. So, the short of it is that horizontal space is a premium, and it can't easily be spared for the search box. I did initially try it in the header, but it didn't feel right. |
materializes from vacation for a few minutes hmm not a lot of feedback ❤️ . I hope this can get in for 19.09! :) disappears back to vacation |
Some feedback from someone who uses a narrow (for today's standards) browser. The index takes up a lot of horizontal space when you're not using it. The python docs handle this really well by allowing you to fold the index. Another thing that has always kinda annoyed me, the toc is super long (multiple accelerated scrolls long), and beginners have no need for it. The main page imo should either be the first section or a short explanation of the important bits of the manual, describing what's in the nixpkgs manual and that other manuals exist, e.g., nix and nixos manuals respectively and why they might want to read those instead (similar treatment for the other manuals). |
I guess you're not going narrow enough :) I do use a narrow column, often, and have chosen what felt like an appropriate breakpoint to put the menu away. Though, I do agree that (maybe as a later step) a control could be added to toggle the menu at any levels. Tasks
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Big 👍 for fixing #68199 even before I opened it.
The tools look great, the only pain point is that docs-build
is somewhat slower than make out/html/index.html
. Maybe it would make sense to split the HTML and EPUB builds. I dream of fast rebuilds with live reloading the HTML page but I doubt there are free XSLT processors that support incremental builds.
doc/multiple-output.xml
Outdated
@@ -189,7 +187,7 @@ | |||
desired outputs or it moves the files during the fixup phase. Each group of | |||
file types has an <varname>outputFoo</varname> variable specifying the | |||
output name where they should go. If that variable isn't defined by the | |||
derivation writer, it is guessed – a default output name is defined, | |||
derivation writer, it is guessed – a default output name is defined, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like to use it too. That’s why I have Compose key enabled:
derivation writer, it is guessed – a default output name is defined, | |
derivation writer, it is guessed – a default output name is defined, |
xmlns:d="http://docbook.org/ns/docbook" | ||
version="1.0"> | ||
<!-- | ||
`ul` option puts the `ul` underneat the parent's `li`, whereas `dd` and `dt` (default) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`ul` option puts the `ul` underneat the parent's `li`, whereas `dd` and `dt` (default) | |
`ul` option puts the `ul` underneath the parent’s `li`, whereas `dd` and `dt` (default) |
@@ -16,6 +17,14 @@ let | |||
paths = [ doclib.standard-tools ] ++ generated-files; | |||
}; | |||
|
|||
# a `docs-generate` command special for a nix-shell, since it | |||
# uses `nix-build` instead of hard-coding a path. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this mean? Where does it use nix-build
?
nixos/doc/manual/module.nix
Outdated
sources = lib.sourceFilesBySuffices ./. [".nix" ".xml"]; | ||
|
||
modulesDoc = builtins.toFile "modules.xml" '' | ||
<section xmlns:xi="http://www.w3.org/2001/XInclude" id="modules"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<section xmlns:xi="http://www.w3.org/2001/XInclude" id="modules"> | |
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude" id="modules"> |
got generated. The HTML will be accessible through the | ||
<filename>result</filename> symlink at | ||
This build will produce a styled and indexed HTML document, and an epub. The | ||
HTML will be accessible through the <filename>result</filename> symlink at | ||
<filename>./result/share/doc/nixos/index.html</filename>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<filename>./result/share/doc/nixos/index.html</filename>. | |
<filename>./result/share/doc/nixos-manual/html/index.html</filename>. |
@samueldr apparently it's about a cm's worth of difference. But when you go narrower you lose the index completely? The nice thing about the python docs is that you can choose whether you want the index visible or not and that it's never inaccessible. |
I have marked a couple of @jtojnar's suggestions as resolved, they were trivial changes or changes I approve, in this WIP branch. There are additional changes in there that I would prefer graham would take a look first :) |
Answering @toonn's question:
Not at all! There are three ways the narrow view allows the user to navigate:
In fact, the narrow view shows more to the user, compared to the full view. Though, in reality the additional navigation at the end of the page is not as trivial to use.
And you're right, it's nice to have the option to toggle it :). |
cc: @toonn → https://stuff.samueldr.com/nixpkgs/manual/
To test the redirection:
Both index.html and index.html-less versions should redirect to the right location. That is because both index.html and index.html-less versions of the page are served by the nixos.org server. I made sure to host the page at a location mimicking the URL structure from nixos.org. |
@samueldr, very nice. All I'm missing is a friendlier "main" page than a detailed TOC like I mentioned earlier and possibly having toggles in the sidebar to open up items and dig down to sub sections. But this is already a major improvement imo. 👍 |
This is out of scope of the PR; contents (except contribution to the documentation) is not part of this PR, considering this reviews the way docs function, both building and using documentation. Though I agree that this is a desirable improvement, to have something more on the main page.
It was tried, but does not work well. Every level of the documentation has a page it links to. This meant that a control only used to toggle the open state of a section in the TOC would have to be implemented. Instead, I deemed it was more user-friendly to simply have one action for the options in the menu "follow and expand". With a local file, the navigation is instant, meaning there is no drawback. With hosted files (e.g. nixos.org) the navigation is near instant, due to the major decrease in page size. The cost in maintaining an additional non-native feature to the documentation is imho not worth the ability the collapse/expand TOC sections at will. That is especially true considering that following a link loses the expanded/collapsed state. |
Then perhaps a static extra level to the TOC? The current sections are too broad imo, making the sidebar less useful. |
|
||
functions/library/generated: doc-support/result | ||
ln -rfs ./doc-support/result/function-docs functions/library/generated | ||
all: ${MD_TARGETS} | ||
|
||
%.section.xml: %.section.md | ||
pandoc $^ -w docbook+smart \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the manual pandoc does not support smart extension for docbook.
What's the deal with the `cd`?? The filename used in the index are relative to cwd/the given path. This means that to produce the expected filename associations, we need to be in the right directory when producing the index. Alternatively, the indexing tool could have been made to strip the leading path from the filenames.
They were always a separate build anyway, but this way it is easier to tell.
Allows for cross-referencing documentation. The way this is built, nixpkgs can depend on nixos, nixos can depend on nixpkgs, without an infinite loop.
7bc1393
to
edd9da1
Compare
62e64c1
to
edd9da1
Compare
|
@grahamc is it known why xslt is too slow. Could be there a switch that only generates the expensive variant for nixos.org and not for local use? |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/documentation-presentation-navigation/6401/3 |
Should we close this PR? |
It does have a large number of conflicts. And not sure what direction the docs are going after the recent rfc and marketing team changes cc @garbas |
@grahamc your time and effort is still appreciated. Thank you for your hard work :) |
:) it was useful to me even if for no other reason than to convince me docbook isn’t worth the fight :).
…On Thu, May 28, 2020, at 6:31 PM, Jon wrote:
@grahamc <https://github.com/grahamc> your time and effort is still appreciated. Thank you for your hard work :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#68020 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAASXLFH6WIZDEZAX2MXHJDRT3Q5FANCNFSM4ITJCMNQ>.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
TLDR:
Motivation for this change
nix-build
was boring.Things done
docbook-index
tool for indexing DocBook against the generated HTML.nix-doc-tools
, a metapackage used for building our documentation.how to write docs for nixos
docs to account for thenix-doc-tools
tooling updates.BTW: nixpkgs and nixos docs are built the same way, so the docs apply to both.
Major thanks to @samueldr for the work on this.
sandbox
innix.conf
on non-NixOS)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)NOT DONE:
nix path-info -S
before and after)Need to determine the impact of building these docs on the minimal ISO.
I'm going on vacation, so I'll be back on the 16th or so to see what y'all think.
btw, samueldr can make fixes to this branch for style/js things :)