Re: [PATCH v3 1/4] docs: allow selecting a Sphinx theme

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Mon, 06 Dec 2021 15:55:50 -0700
Jonathan Corbet <corbet@xxxxxxx> escreveu:

> Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> writes:
> 
> > Em Mon, 06 Dec 2021 12:12:12 -0700
> > Jonathan Corbet <corbet@xxxxxxx> escreveu:
> >  
> >> Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> writes:
> >>   
> >> > Instead of having RTD as an almost mandatory theme, allow the
> >> > user to select other themes via a THEMES environment var.
> >> >
> >> > There's a catch, though: as the current theme override logic is
> >> > dependent of the RTD theme, we need to move the code which
> >> > adds the CSS overrides to be inside the RTD theme logic.
> >> >
> >> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx>
> >> > ---
> >> >
> >> > See [PATCH v3 0/4] at: https://lore.kernel.org/all/cover.1638369365.git.mchehab+huawei@xxxxxxxxxx/
> >> >
> >> >  Documentation/Makefile             |  3 ++
> >> >  Documentation/conf.py              | 52 +++++++++++++++++-------------
> >> >  Documentation/doc-guide/sphinx.rst |  8 +++++
> >> >  3 files changed, 41 insertions(+), 22 deletions(-)    
> >> 
> >> So I'm playing with this now, and definitely want to apply it.  I do
> >> have one little worry, though...  THEME seems like an overly general
> >> name to use here, and seems relatively likely to conflict with other
> >> uses.  THEME= on the command line is fine, but what do you think about
> >> something like DOCS_THEME for the environment variable?  Or even
> >> HTML_THEME as Sphinx uses?  
> >
> > I'm not sure if we will ever consider a "THEME" environment var for anything
> > but docs and html stuff. That's why I ended taking the shortest name (for
> > both THEME and CSS make vars).
> >
> > Yet, I'm OK if to use whatever name you think it would work best.  
> 
> I don't doubt we'll have BPF themes one of these years...:)

Heh, true :-D

> Seriously, though, I was thinking about uses beyond building kernels.
> If I, say, always want to build with the alabaster theme, and so set
> THEME to effect that, will it then mess with my desktop environment or
> some such?

Hmm... makes sense, but worse case scenario, if someone uses some other
software that would conflict with whatever vars we use, he/she could
always place the vars inside a script ;-)

Here, I created this small script for testing a dark theme:

	#!/bin/bash
	set -e

	if [ "$VIRTUAL_ENV" == "" ]; then
		. sphinx_4.3.0/bin/activate
	fi
	cat << EOF > my_css.css
		body {background-color: #0f0f0f; }
		div.body { background-color: #1f1f1f; }
		.sig.c   .k, .sig.c   .kt, .sig.cpp .k, .sig.cpp .kt { color: #17ff17; }
	EOF
	make CSS=my_css.css THEME=groundwork htmldocs

That not only creates a simple CSS file, but also enables the virtual 
environment if disabled.

> A quick search doesn't turn up anything, so probably I'm worrying too
> much.  Maybe I should just apply it as-is, and we can change it if a
> conflict turns up.

Works for me. If you prefer instead that I rename them, just let
me know and I'll send a v4. Or, if you prefer, Feel free to just 
do a:
	sed s,THEME,foo_THEME,g -i patch1
	sed s,CSS,bar_CSS,g -i patch2

before applying the series ;-)

Thanks,
Mauro



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux