linux-kernel - Re: [PATCH RFC 0/5] docs: Improvements to our HTML output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221006060433.38023ecd@sal.lan>
Date:   Thu, 6 Oct 2022 06:04:33 +0100
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     Jonathan Corbet <corbet@....net>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jani Nikula <jani.nikula@...ux.intel.com>
Subject: Re: [PATCH RFC 0/5] docs: Improvements to our HTML output

Em Wed, 05 Oct 2022 09:33:16 -0600
Jonathan Corbet <corbet@....net> escreveu:

> Mauro Carvalho Chehab <mchehab@...nel.org> writes:
> 
> > I would play with the sidebar options used by Alabaster in order to
> > try to make the TOC more useful.  
> 
> Definitely worth doing; I'm not sure how much flexibility there is
> there.
>
> I'd *really* like to avoid carrying our own theme if at all possible...

Yeah, agreed. 

Btw right now if you don't have RTD installed, it will already fallback to 
classic Sphinx-native theme, on a non-optimized way, as it will be using the
CSS wrote for RTD.

> The right solution might be to actually split the books apart and do the
> intersphinx thing; I've not really looked into that at all.

Yeah, we've been postponing using intersphinx for quite a while. Perhaps
we could start supporting it. One expected advantage would be to make
life easier when building just a single book, as intersphinx should keep
the cross-references working and it should not produce extra warnings due 
to references that belong to other books.

> > On a side note, one thing I miss on all default themes is a way to dynamically
> > use dark mode. That's btw why I ended adding non-default support for 
> > 'sphinx_rtd_dark_mode' (which also requires an external package). At the time
> > I added CSS/themes customization support to the build system, this was the only 
> > theme that allowed to switch to either dark/light mode. It would be really cool 
> > if Alabaster (or some other default themes) could honor the user's preference
> > between light/dark modes.  
> 
> Yeah, Alabaster doesn't seem to have that.  Providing that ability in
> conf.py shouldn't be *that* hard to do; it doesn't use that many colors,
> though there might be a fair amount of CSS to override.

RTD dark mode [1] solves it in runtime using a CSS with:

	html[data-theme='dark'] body {
	  color: #bfbfbf;
	}

A JS sets "data-theme" to dark in order to activate it in runtime[1] with:

	    document.documentElement.setAttribute('data-theme', 'dark');

It also comes with a .py file that selects the default.

But yeah, there are a fair amount of CSS to override.

Also, I suspect that maintaining it can be a challenge. Not sure if it
worth the efforts.

[1] https://github.com/MrDogeBro/sphinx_rtd_dark_mode/tree/main/sphinx_rtd_dark_mode

Regards,
Mauro