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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20211207102038.1e8a4f8c@coco.lan>
Date:   Tue, 7 Dec 2021 10:20:38 +0100
From:   Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To:     Jonathan Corbet <corbet@....net>
Cc:     Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Akira Yokosawa <akiyks@...il.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        " NĂ­colas F. R. A. Prado" <nfraprado@...tonmail.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Andrew Klychkov <andrew.a.klychkov@...il.com>,
        Miguel Ojeda <ojeda@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/4] docs: allow selecting a Sphinx theme

Em Tue, 7 Dec 2021 10:16:22 +0100
Mauro Carvalho Chehab <mchehab+huawei@...nel.org> escreveu:

> Em Mon, 06 Dec 2021 15:55:50 -0700
> Jonathan Corbet <corbet@....net> escreveu:
> 
> > Mauro Carvalho Chehab <mchehab+huawei@...nel.org> writes:
> >   
> > > Em Mon, 06 Dec 2021 12:12:12 -0700
> > > Jonathan Corbet <corbet@....net> escreveu:
> > >    
> > >> Mauro Carvalho Chehab <mchehab+huawei@...nel.org> 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@...nel.org>
> > >> > ---
> > >> >
> > >> > See [PATCH v3 0/4] at: https://lore.kernel.org/all/cover.1638369365.git.mchehab+huawei@kernel.org/
> > >> >
> > >> >  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 ;-)

On a second thought, I'd like to adjust the description of patch 4,
so I'll re-send the series anyway. So, I'll submit v4 with:

 	sed s,THEME,DOCS_THEME,g -i patch1
 	sed s,CSS,DOCS_CSS,g -i patch2

Thanks,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ