<feedxmlns="http://www.w3.org/2005/Atom"><title>LEdoian's Blog - technology</title><linkhref="https://blog.ledoian.cz/"rel="alternate"></link><linkhref="https://blog.ledoian.cz/feeds/technology.atom.xml"rel="self"></link><id>https://blog.ledoian.cz/</id><updated>2024-04-17T15:18:00+02:00</updated><entry><title>Creating own XKB tweaks</title><linkhref="https://blog.ledoian.cz/custom-xkb-tweaks.html"rel="alternate"></link><published>2024-04-17T15:18:00+02:00</published><updated>2024-04-17T15:18:00+02:00</updated><author><name>LEdoian</name></author><id>tag:blog.ledoian.cz,2024-04-17:/custom-xkb-tweaks.html</id><summarytype="html"><p>Debugging this took me a bit too long, so I want to write about the caveat.</p>
<p>My problem: My laptop does not have PageUp and PageDown keys, and many other
keyboards I use have similar deficiencies. And I use various environments and
various systems, some of which are shared with …</p></summary><contenttype="html"><p>Debugging this took me a bit too long, so I want to write about the caveat.</p>
<p>My problem: My laptop does not have PageUp and PageDown keys, and many other
keyboards I use have similar deficiencies. And I use various environments and
various systems, some of which are shared with other people who don't need/want
my tweaks. IOW: I want something generic, but it must be confined to my user –
no system-wide daemon, no udev remapping. (I mostly ended up with these
solutions when I searched for a way to remap keys on Wayland.)</p>
<p>Requirements: xkbcommon implementation of XKB with utilities. It is quite
common these days (duh…), but you could probably just compile this yourself if
you don't have it.</p>
<div class="section" id="the-tweaking">
<h2>The tweaking</h2>
<p>The <a class="reference external" href="https://xkbcommon.org/doc/current/user-configuration.html">xkbcommon guide</a> tells us that we
can inspect the files in <a class="footnote-reference" href="#lazy" id="footnote-reference-1">[1]</a><tt class="docutils literal">/usr/share/X11/xkb</tt> for the source files
and just write our bits to <tt class="docutils literal"><span class="pre">~/.config/xkb/symbols/ledoian</span></tt>. In particular, I
added this snippet to remap keyboard brightness controls to PageUp/Down:</p>
<pre class="literal-block">
partial
xkb_symbols &quot;qs&quot; {
key &lt;I238&gt; {[ Prior ]};
key &lt;I237&gt; {[ Next ]};
};
</pre>
<p>The key identifiers are taken e.g. from <tt class="docutils literal">xkbcli <span class="pre">interactive-wayland</span></tt>.
However, this is KcCGST <a class="footnote-reference" href="#kccgst-vs-rmlvo" id="footnote-reference-2">[2]</a> description, but layouts are
configured using RMLVO, so I need to define an option and tell what it should
do. The guide wants me to create <tt class="docutils literal"><span class="pre">~/.config/xkb/rules/evdev</span></tt> with:</p>
<pre class="literal-block">
! option = symbols
ledoian:qs = +ledoian(qs)
! include %S/evdev
</pre>
<p>Now I just add <tt class="docutils literal">ledoian:qs</tt><a class="footnote-reference" href="#option-vs-symbol" id="footnote-reference-3">[3]</a> to my keyboard configuration
and… it does not work. For this, at all, but if I remap e.g. the L key, that
gets applied. The problem? That included file says that the default keyboard
model always includes <tt class="docutils literal">inet(evdev)</tt> symbols. Those symbols set the default
meaning of the keys, but since that got applied later, it overrides my tweak.</p>
<p>Solution: first include, then add my option.</p>
<p>How to debug: read stuff that <tt class="docutils literal">xkbcli <span class="pre">compile-keymap</span><span class="pre">--verbose</span></tt> tells you
(pass your config as <tt class="docutils literal"><span class="pre">--layout</span></tt>, <tt class="docutils literal"><span class="pre">--variant</span></tt>, <tt class="docutils literal"><span class="pre">--options</span></tt>, …). At the top
it says what it does:</p>
<pre class="literal-block">
xkbcommon: DEBUG: Include path added: /home/ledoian/.config/xkb
xkbcommon: DEBUG: Include path added: /usr/share/X11/xkb
xkbcommon: DEBUG: Compiling from RMLVO: rules 'evdev', model 'pc105', layout 'us', variant '(null)', options '(null)'
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-1">[1]</a></td><td>This is not technically accurate, really the paths reference
<tt class="docutils literal">$XDG_something</tt> variables. I am lazy and just copied my system, so YMMV
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-2">[2]</a></td><td>There are two levels of describing the keymap: the
lowlevel one is called KcCGST (short for keycodes, compat, geometry,
symbols, types) and is considered to be an implementation detail; the
user-facing one is RMLVO (rules, model, layout, variant, options) and that
is what you use in the configs, with <tt class="docutils literal">setxkbmap</tt>&amp;c.</td></tr>
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-3">[3]</a></td><td>While both this example and the <a class="reference external" href="https://www.freedesktop.org/wiki/Software/XKeyboardConfig/">upstream</a> layouts name
the symbols and options similarly, I think they don't need to be related –
you should be able to put whatever you want in your options to the left of
<tt class="docutils literal">=</tt>, the right hand side is the name of the symbol file and if a
non-default layout from that file is used, its name is put in the
parentheses.</td></tr>
</tbody>
</table>
</div>
</content><categoryterm="technology"></category><categoryterm="lifehack"></category><categoryterm="software"></category><categoryterm="linux"></category></entry><entry><title>Print your stuff on Möbius bands!</title><linkhref="https://blog.ledoian.cz/mobius-print.html"rel="alternate"></link><published>2024-03-02T18:07:00+01:00</published><updated>2024-03-03T14:59:00+01:00</updated><author><name>LEdoian</name></author><id>tag:blog.ledoian.cz,2024-03-02:/mobius-print.html</id><summarytype="html"><p>I found a fun and useful way of printing stuff to ~~both~~all sides of a paper.
<h2>Quick recap: how to conventionally print stuff two-sided</h2>
<p>A typical way is just sending the page to get printed two-sided (with setting
the correct way …</p></div></summary><contenttype="html"><p>I found a fun and useful way of printing stuff to ~~both~~all sides of a paper.
<p>Booklets are fun and approachable, but still suffer from the same issues as the
conventional duplex print. They might be a bit hard to print, but programs like
<tt class="docutils literal">pdfbook</tt> or <tt class="docutils literal">paperjam</tt> make it easy to prepare for the classic duplex
printing. Also, it is maybe hard to tell which page ends up where, as the order
is: last+first, second+penultimate, third-from-end+third, … until the pages
<p class="caption">The &quot;Möbius order&quot; of pages.</p>
</div>
<p>And this is really easy to use: You read a page and when you don't need it
anymore, you flip it and put to the end of the page stack <a class="footnote-reference" href="#ordering" id="footnote-reference-2">[2]</a>. If you
need to look at several pages, just rotate them in the same order as they go the
first time. <a class="footnote-reference" href="#mistake" id="footnote-reference-3">[3]</a></p>
<p>Need to print this? For one-sided printers this is rather easy, too: just print
the first half (the bigger one) on the sheets, then put them back into the tray
and print the rest on them. You might need to experiment which side the sheets
should be put in and whether you need to print the rest in reverse order, but
that is it.</p>
<p>Got the pages shuffled? Sort them by the first half, as if the print was
one-sided.</p>
<p>The only annoying thing for me is that there is not much software that could
reorder the pages for two-sided printing, so that you don't need to re-insert
the sheets back in the tray. So I <a class="reference external" href="https://blog.ledoian.cz/images/mobius-print/interleave.patch">patched</a><a class="reference external" href="https://mj.ucw.cz/sw/paperjam/">paperjam</a> to enable this. <a class="footnote-reference" href="#multi-mobius" id="footnote-reference-4">[4]</a></p>
<p>And the best part? If you would try to glue consecutive pages side-to-side,
you'd end up with a Möbius band! So if you get a Möbius paper, you can just
<td><tt class="docutils literal">book</tt> (follow with <tt class="docutils literal">nup(2)</tt> for actual booklet print)</td>
</tr>
<tr><td>Leporello</td>
<td><tt class="docutils literal">modulo(2) {1 2} modulo(1,half) {1 <span class="pre">-1}</span></tt> (The first <tt class="docutils literal">modulo</tt> just adds blank pages to the end.)</td>
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-1">[1]</a></td><td>Most of the figures in this article are drawn with a single
page per a side of a sheet. I consider putting more pages on a single side
of paper to be an implementation detail, because it is not always possible
(e.g. with too small font) and sometimes you could put more than two pages
on a single side of paper, which leads to the fact that if you put
everything on one side of the paper, you can see everything at once and save
the other side. Not very useful though… My only exception is the booklet
printing below, because that one seems to be rather common.</td></tr>
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-2">[2]</a></td><td>See how this neatly puts the first-past-half page right after
the half of the stack? Awesome!</td></tr>
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-3">[3]</a></td><td>Also, if you flip the page around the wrong edge, you can just
rotate the rest of the stack and end up with the correct orientation.</td></tr>
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-4">[4]</a></td><td>A slight variation for which I can generate the order
with upstream <tt class="docutils literal">paperjam</tt> is using this order on small subsets of pages.
For example, if you only want to be able to see any two consecutive pages,
you can do this for just four pages – the order is then 1+3, 2+4, 5+7, 6+8,…
Since each sheet either contains two odd or two even pages, the following
page is on different sheet than the previous one. And you can do this
&quot;modulo 3&quot; to see three pages: 1+4, 2+5, 3+6, 7+10, … This &quot;simulates&quot;
multiple smaller Möbius bands, but will be probably harder to use.</td></tr>
</tbody>
</table>
</div>
</content><categoryterm="technology"></category><categoryterm="lifehack"></category><categoryterm="print"></category></entry><entry><title>About this blog</title><linkhref="https://blog.ledoian.cz/about-blog.html"rel="alternate"></link><published>2024-01-10T16:47:00+01:00</published><updated>2024-01-10T16:47:00+01:00</updated><author><name>LEdoian</name></author><id>tag:blog.ledoian.cz,2024-01-10:/about-blog.html</id><summarytype="html"><p>This is my blog and this article describes its setup and other details about my
intentions. The actual <a class="reference internal" href="#the-setup">setup</a> is probably the most
interesting tech-wise.</p>
<div class="section" id="what-is-this">
<h2>What is this?</h2>
<p>My own space on the internet where I can post whatever and link others to it.
It might end up containing rants …</p></div></summary><contenttype="html"><p>This is my blog and this article describes its setup and other details about my
intentions. The actual <a class="reference internal" href="#the-setup">setup</a> is probably the most
interesting tech-wise.</p>
<div class="section" id="what-is-this">
<h2>What is this?</h2>
<p>My own space on the internet where I can post whatever and link others to it.
It might end up containing rants, guides, ideas, or maybe nothing at all in the
end. Only the future will tell.</p>
<p>The blog might even serve as my personal web page/introduction. Maybe. Maybe not…</p>
<p>The main motivation is to have low-effort way to post random stuff. Which leads
to my requirements for this thing.</p>
</div>
<div class="section" id="requirements">
<h2>Requirements</h2>
<p>(The requirements are a bit too idealistic, so not all of them were satisfied…)</p>
<ul class="simple">
<li>low-effort, me-friendly, low-maintenance – I don't want to have to learn too
many new technologies to use this. This includes the required technologies:
<li>Technical and math content ~~friendly~~ compatible – I expect that to appear
here.</li>
<li>Static site – for security, coolness factor and control. Also static on the
front-end, because I don't like JavaScript and/or running untrusted code on
my machine (even when in a sandbox). The SSG should likely be aimed at
creating blogs, not documentation. Also, self-contained, as in not depending
on third-party sites.</li>
<li>No moving parts in the infrastructure (or as few as possible) – if it works
on my machine, it should just get mirrored to the public site with as few
modifications as possible.</li>
<li>Transparent – I should be able to understand it, maybe others could also use
it as a resource or take inspiration. (At one point, this deployment itself
started being interesting, so if I can share the background as well as the
final webpage, it would be cool.)</li>
<li>Followable – I know you internet guys like to ~~stalk~~ follow people :-)</li>
<li>Aligned with my values: minimalist, simple, extensible/hackable, FLOSS</li>
<li>If the platform could distinguish translations and do strikethroughs, it would
be nice, but that is not a hard requirement.</li>
</ul>
<p>There are several features of conventional blogs that I consider to be a
non-goals or even anti-goals. Mostly it is about interactivity – I don't aim
for having any kind of comments here, or really anything that would require
JavaScript or complex HTML/CSS. And appearance goes past me as well, I instead
try to let the browser decide how to display this page – more on that <a class="reference internal" href="#design-considerations">below</a>.</p>
<p>The workflow I wanted to achieve is something like: Write the content, git it,
build it (locally, no CI/CD), push it, done. Single write, single push, very
simple.</p>
<p>And I managed to achieve something like that, via learning (too much?) about
git.</p>
<!-- TODO: fix the worktree bug already! -->
</div>
<div class="section" id="the-setup">
<h2>The setup</h2>
<p>Naturally for a sysadmin/netadmin, the setup consists of 7 ~~ISO/OSI~~ layers:</p>
<ol class="arabic simple">
<li><strong>Physical layer</strong>: cheap Hetzner VPS. Not physical, but whatever.</li>
<li><strong>Persistence layer</strong>: <a class="reference external" href="https://gitea.ledoian.cz/LEdoian/blog">this git repo</a>. I will elaborate below why can
you see this both rendered here and in the source form in Forgejo.</li>
<li><strong>Content layer</strong>: Markdown or reStructuredText files.</li>
<li><strong>Business logic layer</strong>: <a class="reference external" href="https://getpelican.com">Pelican</a>. It's rather
popular and written in Python, I didn't look further.</li>
<li><strong>Presentation layer</strong>: I hacked my own theme, because I didn't like any in
the <a class="reference external" href="https://github.com/getpelican/pelican-themes">pelican-themes repo</a>.
I was a bit inspired by the layout of <a class="reference external" href="https://eev.ee/blog">eevee's blog</a>, but I wanted a dark theme. And as you can see, I
can't do quality frontend, so it ended up horrible… :-D</li>
<li><strong>Stalking layer</strong>: Pelican's built-in RSS and Atom feed generators. Not
linked from anywhere at the moment, but <a class="reference external" href="https://gitea.ledoian.cz/LEdoian/blog/src/branch/blog/output/feeds">the repo will tell you</a> what
hides under the <tt class="docutils literal">/feeds/</tt> path. Or you can utilize the repo (for personal
use – the content's license is not decided at the moment)…</li>
</ol>
<p>Most of this is straightforward, the fancy part is my repo. The repo contains
both source and rendered content, so that I can point Nginx right at a checkout
and have Git solve both persistence and deployment without additional moving
parts.</p>
<p>There are two tricks in the configuration of Git repositories: pushing to a
checked out repo is enabled by configuring <tt class="docutils literal">receive.denyCurrentBranch =
updateInstead</tt> in the target repository (which is just a normal repo, not a
bare one), and then I just told my source repositories <a class="footnote-reference" href="#multiple-src" id="footnote-reference-1">[1]</a> to use
two push targets for the remote (the first line <em>replaces</em> the original push
<p>The blog user is just a user with SSH access via authorized keys, no special
sauce there. Nginx is then pointed to serve <tt class="docutils literal">~blog_user/blog_dir/output/</tt> at
<tt class="docutils literal">blog.ledoian.cz</tt>. (The <tt class="docutils literal"><span class="pre">git-remote(1)</span></tt> manpage requires me to have both
repositories in sync, but as long as I configure all my repositories this way,
I should be safe, and I think I could get away with my blog checkout getting
<h2>My workflow and lots of drafts</h2>
<p>It's Git so it's only natural for me to use various branches and repositories
even for a dumb blog. There are in fact 4 stages an article may go through <a class="footnote-reference" href="#skipping-stages" id="footnote-reference-2">[2]</a>:</p>
<ol class="arabic">
<li><p class="first">A private draft: lives on a branch <tt class="docutils literal">priv/something</tt>, may contain private
infos (like when I would just copy-paste from terminal without redaction)
and this branch will probably never be merged to the main repo. Nothing
about these branches is guaranteed.</p>
</li>
<li><p class="first">A public WIP draft: uses a branch called <tt class="docutils literal">pub/something</tt> which is pushed
to Forgejo (and in fact also to the blog itself, but that is just an
implementation detail). The draft is either does not build or is very
incomplete and I expect to add stuff in a way that could break the build, so
I put it on a separate branch. The branch will be probably merged to the
main branch (called <tt class="docutils literal">blog</tt>) when it is ready.</p>
<p>The <tt class="docutils literal">pub/…</tt> branches can be created either manually or by cherry-picking
from the respective <tt class="docutils literal">priv/…</tt> branch, but that will likely not be
distinguishable. (I am too lazy to keep the references even in the commit
logs.)</p>
</li>
<li><p class="first">When a draft is almost ready (or the content has simple syntax), it gets
placed on the <tt class="docutils literal">blog</tt> branch. The only thing that designates it as a draft
is <tt class="docutils literal">status: draft</tt> in the frontmatter, which means that the article will
get rendered and put somewhere on the public blog, but not reachable from
the title page (&quot;unlisted&quot;).</p>
</li>
<li><p class="first">Of course, eventually (and hopefully) the article gets published for
everyone to see. At that point, it is complete (or at least that is what I
thought when marking it as published). Possibly it might be updated in the
future, but no such update is anticipated at the moment of publishing. <a class="footnote-reference" href="#update-this" id="footnote-reference-3">[3]</a></p>
</li>
</ol>
<p>I use Git to synchronize my private branches among machines, so there are
actually two &quot;server-side&quot; repositories (private and public one) and thus two
<p>As for the actual workflow, for the main branch it usually consists of: writing
content, committing it, building the web, checking it locally, committing the
built blog and pushing it. Sometimes I do the commits together, but I always
separate the rendering/building commits from the content-creating ones, so that
I can handle those differently if needed (i.e. there is no point in
cherry-picking the built content, I can generate it). <a class="footnote-reference" href="#git-purists" id="footnote-reference-5">[5]</a></p>
<p>For other branches I use some applicable subset of the steps above, probably.</p>
<p>The appearance of the blog is maybe not nice. That is for two reasons: I don't
have the right idea about how to make it much better and I want to have a
rather simple CSS for the web. The latter wish is because I tend to tweak
appearance of sites I visit using my own styles, so I would like you to be able
to do the same.</p>
<p>And for the former reason, if you have any ideas / improvements (including user
styles), hit me at <a class="reference external" href="mailto:blog&#64;pokemon.ledoian.cz">blog&#64;pokemon.ledoian.cz</a> :-)</p>
<p>My overall idea is a dark-by-default <a class="footnote-reference" href="#light-theme" id="footnote-reference-6">[6]</a> minimalist page with a single menu on the
right containig all the relevant links. The page should not dictate too much
but rather let the user agent decide the rendering (<a class="reference external" href="https://html.spec.whatwg.org/multipage/rendering.html#rendering">it does anyway…</a>).</p>
<p>I want my blog to render similarly in Gecko-, WebKit- and Blink-based browsers
(e.g. Firefox, Badwolf, Qutebrowser). Others should be usable.
Browser-/engine-specific styles are not welcome – let's keep it simple. And no
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-1">[1]</a></td><td>I also use multiple machines on which I can write stuff.</td></tr>
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-2">[2]</a></td><td><p class="first">I am lazy and chaotic (good), so the stages are optional
and non-linear, and sometimes involve paper. This article is a prime
example: parts of it were on two different private branches, but at the end
I wrote it from scratch directly on the main branch. And the requirements
were written on a paper originally.</p>
<p class="last">Nevertheless, the general idea still holds and may inspire others, so it
makes sense to keep this part in the article. (Also, this footnote might not
make sense before reading the definition of the stages, but I didn't find a
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-3">[3]</a></td><td>Well, given this article contains some future plans, I
actually anticipate update of this one, but maybe not in the near future. So
the outline is not really correct, but I make the rules :-) (There
were some build breaks on the main branch, too :-D)</td></tr>
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-4">[4]</a></td><td>I would love if my Forgejo could have &quot;private
branches&quot;, but I understand that the overhead for doing this is not nice,
since it would need to be able to decide for any object, whether it is
public or not (you can do <tt class="docutils literal">git fetch &lt;remote&gt; <span class="pre">&lt;object-hash&gt;</span></tt>) and somehow
keep track even with rebases, merges, force-pushes, many branches, … Having
a separate private repository is not a big problem in comparison.</td></tr>
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-5">[5]</a></td><td>Git purists might want to tell me that committing build
artifacts is not good practice. I know and I explicitly don't care in case
of this repo, because here I prioritise my own comfort of being able to
check everything locally and then be reasonably sure the deployed version
will also work, all this with only a single push somewhere. Of course, one
could argue that with that there is no reason to create two commits, but it
does not really bother me to run something like <tt class="docutils literal">git commit <span class="pre">-m&quot;render&quot;</span>
output/</tt> when I am sure it works, and this keeps readable diffs separate
from the non-readable ones (i.e. the changes in generated HTML).</td></tr>
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-6">[6]</a></td><td>Having the page be dark-by-default is my preference, but I
respect that others may prefer light sites. However, I have not yet
determined what colors should be used (probably still cyan / blue / maybe
purple-ish, but I don't know what shade) nor understood how to use
<tt class="docutils literal"><span class="pre">&#64;media(prefers-color-scheme)</span></tt> in a maintainable and simple way (in the
context of my theme). So naturally, this is postponed to the future…</td></tr>
