Copy large files to Nextcloud

I'm running my own Nextcloud instance in a [docker container][nc-docker] with the `data` directory mounted from a local folder on my disk.
Unfortuantely it's not very satisfying to use the web UI or using a [davfs2 mount][nc-davfs2] of the disk to copy large files to the Nextcloud instance.
This is because files must be passed through the full [LAMP stack][lamp] which involves a lot overhead and slows down any large file uploads.

An alternative to upload files via the browser or WebDAV is to copy them directly into the user data folder and then force Nextcloud to sync the content with its internal file cache and database entries.

Say our Nextcloud instance data lives in `/opt/nextcloud/data` and our source files live in `/tmp/stage` on the server.
Further let the Nextcloud username be `my-user` and say the source data should be copied to `~/my-folder` in Nextcloud.

Copying the data would then look like this:

```bash
# copy files
rsync -avP /tmp/stage/ /opt/nextcloud/data/my-user/files/my-folder/
# fix permissions
chmod www-data:www-data /opt/nextcloud/data/my-user/files/my-folder
```

It's necessary to fix the permissions since the [default user][nc-default-user] in the [official Nextcloud docker images][nc-docker] is the `www-data` user.
See also the [Nextcloud documentation][nc-file-operations].
Details:

```console
$ docker-compose exec nextcloud id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)
```

After the files have been copied, Nextcloud must be forced to re-index all files within this directory:

```console
$ docker-compose exec -u www-data nextcloud ./occ files:scan --path="/my-user/files/my-folder"
Starting scan for user 1 out of 1 (my-user)
+---------+-------+--------------+
| Folders | Files | Elapsed time |
+---------+-------+--------------+
| 6       | 354   | 00:00:01     |
+---------+-------+--------------+
```

The internal database and caches have been updated and your files will pop up in the web UI afterwards.

[nc-docker]: https://hub.docker.com/_/nextcloud/
[nc-davfs2]: https://docs.nextcloud.com/server/16/user_manual/files/access_webdav.html
[nc-default-user]: https://github.com/nextcloud/docker/blob/b23910be9215f8338aee419007feb70cdacb7741/20.0/apache/entrypoint.sh#L16
[nc-file-operations]: https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/occ_command.html#file-operations
[lamp]: https://en.wikipedia.org/wiki/LAMP_%28software_bundle%29

Pi-hole User Group Management

At home I have a [Pi-hole] in service which acts as my central DNS provider for all devices in my network.
This means that by default all devices share the same filter lists, so effectively ads are blocked on all devices.

This setup is most likely the setup most people need and prefer.
For our home it's not working, because some devices should see clear and unfiltered DNS entries.
Let's see how we can exclude certain devices from the filter lists.

## Pi-hole Group Management

Since [Pi-hole v5.0][pi-hole-v5-release-notes], which has been released in 2020-05, groups can be configured.
Known devices can be put into groups which can have different filter lists assigned to them.
The group management can be found under `http(s)://my-pi.hole/admin/groups.php`.

In my setup I created a group for all my devices which I named `dotcs`.

![Pi-hole Admin: Group management](/posts/<post_slug>/pihole-admin-groups.png)

By default this group does nothing.
First devices need to be assigned to the group.
Those settings can be found under `http(s)://my-pi.hole/admin/groups-clients.php`.

![Pi-hole Admin: Device management](/posts/<post_slug>/pihole-admin-devices.png)

After that the adlists need to be configured and attached to the group.
In my case I removed all of the lists from the `default` group and attached them only to the `dotcs` group.

![Pi-hole Admin: Adlist management](/posts/<post_slug>/pihole-admin-adlists.png)

With this configuration all devices listed in the `dotcs` group see filtered DNS entries whereas all other devices see unfiltered DNS entries.

*Thanks to the Pi-hole developers for this awesome feature and please consider [donating to the project][pi-hole-donation] if you like it.*

[pi-hole]: https://pi-hole.net/
[pi-hole-v5-release-notes]: https://pi-hole.net/2020/05/10/pi-hole-v5-0-is-here/#page-content
[pi-hole-donation]: https://pi-hole.net/donate/


How to deploy a Next.js application to GitHub pages

[Next.js] is becoming very popular - for good reasons.
To me it's one of the best frameworks out there to create all kinds of web pages that are based on [React].
Since Next.js does allow for full server-side rendering and [static html exports][next-static], pages can be rendered completely on the server and delivered to the client as dump static HTML pages with a little bit of CSS and JavaScript where needed.
This makes them perfectly suitable to be hosted on [GitHub pages][github-pages].

My first thought was: Yeah, easy let's do this quickly.
But not so fast!
I've leared that there are a few things that require tweaks.

## Use GitHub Actions to build and export Next.js pages

I use GitHub actions to build the static pages.
The corresponding project setting is set to deliver pages from the `gh-pages` branch.

![GitHub Pages settings to deliver from branch gh-pages](/posts/<post_slug>/github-pages-settings.png)

The corresponding `.github/workflows/gh-pages.yml` is simple.
Note that the `npm run export` script has an enviroment variable `DEPLOY_TARGET: gh-pages` attached to it.
This env variable will be used in the second step.
In the deploy step the branch is set to `gh-pages` and we deliver results from the `out` folder, which is the default target folder for the `next export` command.

Also note that the pipelie creates the (empty) file `out/.nojekyll`.
This is necessary to bypass Jekyll processing on GitHub pages as mentioned [here][gh-pages-jekyll].
Otherwise folders that start with an underscore are ignored, but Next.js puts merged assets, e.g. CSS and JS files, into a folder `_next`. 😵

```yaml
name: Build and Deploy
on:
  push:
    branches:
      - master
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2.3.1
        with:
          persist-credentials: false

      - name: Install and Build
        uses: actions/setup-node@v1
      - run: npm install
      - run: npm run build     # runs `next build`
      - run: npm run export    # runs `next export`
        env:
          CI: true
          DEPLOY_TARGET: gh-pages
      - run: touch out/.nojekyll

      - name: Deploy
        uses: JamesIves/github-pages-deploy-action@3.7.1
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          BRANCH: gh-pages  # The branch the action should deploy to.
          FOLDER: out       # The folder the action should deploy.
          CLEAN: true       # Automatically remove deleted files from the deploy branch
```


## Rewrite paths to static files

When serving websites via `<username>.github.io` any static assets must point to `<username>.github.io/<projectname>` with `<projectname>` being the name of the repository (typically again `<username>.github.io`).
GitHub Pages rewrites some paths internally, so that they **appear** to come from `<username>.github.io`, but things will not work out if the `<projectname>` part is missing.

`next export` allows to set a `assetPrefix`, which tweaking the URL paths and re-write them from `/` to `/<assetPrefix>/`.
This can be configured in the project's `next.config.js`:

```js
const ghPages = process.env.DEPLOY_TARGET === 'gh-pages';

module.exports = {
  assetPrefix: ghPages ? '/dotcs.github.io/' : ''   // customize this value
};
```

With this line in place we detect if we're executed by the GitHub Action runner and re-write paths accordingly.

## Success

With those tweaks Next.js pages can be hosted via GitHub pages easily.
You just need to be aware of them. 😉


[next.js]: https://nextjs.org
[react]: https://reactjs.org
[next-static]: https://nextjs.org/docs/advanced-features/static-html-export
[redux]: https://redux.js.org
[react-hooks]: https://reactjs.org/docs/hooks-intro.html
[github-pages]: https://pages.github.com
[gh-pages-jekyll]: https://github.blog/2009-12-29-bypassing-jekyll-on-github-pages/

Migrate from i3 to sway

I recently changed from the Linux display server protocol [X.org Server][xserver] to [Wayland][wayland] on one of my machines.
My favorite window manager [i3] is not compatible with Wayland though, so I had to search for an alternative.
Luckily there is a drop-in replacement for i3 available which is named [Sway][sway].

Sway is very similar to i3, it even uses the same syntax for the config, so the change required only a few tweaks which I will now talk about.
I can also recommend to read the [Sway article on the Arch Wiki][sway-archwiki].

At this let's take a brief moment to say "Thank you" to all contributors of Sway and Wayland and maintainers of the corresponding packages in the various distros out there. ♥

## Installation

Installation of sway under Arch Linux is easy.
It's as simple as:

```bash
yay -S sway
```

## Copy configuration

Sway searches it's configuration in `~/.config/sway/config` so I copied my i3 config there.
All changes go into this config file.

## Adjust configuration

After the configuration has been copied use a separate TTY to try our sway and its configuration.
Remember that `<SUPER> + SHIFT + c` does reload your configuration which is quite handy for trying things out.
Also `swaymsg` can be used to send messages to sway, so for example the following command would set the scaling 2 for all output devices.

```
swaymsg output "*" scale 2
```

### Screen output resolution

I'm working with a HiDPI screen which was detected correctly in Sway.
But I found the scaling factor of 2, which is the default in HiDPI screens, too much.
Although it's not recommended to use float values here, I found a scaling factor of 1.3 to fit my needs, so I added this line to my config:

```
# Screen scaling (default is 2)
output eDP-1 scale 1.3
```

To list connected displays use `swaymsg -t get_outputs` which in my case now (after the change) shows as:

```console
$ swaymsg -t get_outputs   
Output eDP-1 'Apple Computer Inc Color LCD 0x00000000' (focused)
  Current mode: 2560x1600 @ 59.972000 Hz
  Position: 0,0
  Scale factor: 1.300000
  Scale filter: linear
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 4
  Max render time: off
  Adaptive sync: disabled
  Available modes:
    2560x1600 @ 59.972000 Hz
```

### Background images with automatic rotation

I like to have randomly chosen background images that change every now and then.
Sway makes it easy to implement this.
I added the following line to my config which executes a script during start.

```
exec --no-startup-id ~/.local/scripts/sway-rotate-bg-image.sh
```

The script itself doesn't do much.
It lists all files in a certain folder, shuffles the names and selects one of them.
It updates the background on all attached displays image via `swaymsg` and then pauses for 300 seconds (=5min) before the next iteration.

```bash
#!/usr/bin/env bash
IMG_DIR=~/wallpapers
while true;
do
    IMG=`ls -t1 $IMG_DIR/* | shuf | head -n 1`
    swaymsg output "*" bg $IMG fill; sleep 300
done
```

### Detect idle state and lock screen

To automatically lock the screen there are luckily two programs available that do the heavy-lifting.
They are called swayidle and swaylock and can be installed in Arch via:

```bash
yay -S swayidle swaylock
```

The following script is taken from the `swayidle` manpage:

> This will lock your screen after 300 seconds of inactivity, then turn off your displays after another 300 seconds, and turn your screens back on when resumed. It will also lock your screen before your computer goes to sleep.
>
> To make sure swayidle waits for swaylock to lock the screen before it releases the inhibition lock, the -w options is used in swayidle, and -f in swaylock.

```
exec --no-startup-id swayidle -w \
    timeout 300 'swaylock -f -c 000000' \
    timeout 600 'swaymsg "output * dpms off"' \
    resume 'swaymsg "output * dpms on"' \
    before-sleep 'swaylock -f -c 000000'
```

### Screen backlight keys

In my i3 setup I used `xbacklight` to change the backlight of my screen.

```
bindsym XF86MonBrightnessUp exec xbacklight +10
bindsym XF86MonBrightnessDown exec xbacklight -10
```

This of course won't work anymore in Wayland, so I replaced the old configuration with `brightnessctl` which needs to be installed first:

```bash
yay -S brightnessctl
```

The syntax of `brightnessctrl` differs slightly:

```
bindsym XF86MonBrightnessDown exec brightnessctl set 5%-
bindsym XF86MonBrightnessUp exec brightnessctl set +5%
```

### Keyboard bindings

For me one key on the keyboard is completely superfluous: capslock.
In my systems I either deactivate this key or map it to ESC if possible.
Having ESC closer to the home row is benefitial to me - especially when working a lot with vim.
This can done with xkb_options.

Another interesting setting is the key repeat delay and rate, which can be tuned also quite easily.

```
input "type:keyboard" {
    # Capslock key should work as escape key
    xkb_options caps:escape

    repeat_delay 350
    repeat_rate 45
}
```

### SSH Agent

To automatically start the SSH agent I use a systemd service which is placed in `~/.config/systemd/user/ssh-agent.service`:

```ini
[Unit]
Description=SSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
# DISPLAY required for ssh-askpass to work
Environment=DISPLAY=:0
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target
```

Also configure the pam environment in `~/.pam_environment`:

```bash
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/ssh-agent.socket"
```

Then start the service and enable it for future system starts: `systemctl --user enable --now ssh-agent.service`.

### Exit script

Finally I updated my exit script that allows me to lock my screen, suspend, shutdown or reboot my machine, etc.

The Sway configuration looks as this

```
set $mode_system System (1) lock, (e) logout, (s) suspend, (h) hibernate, (r) reboot, (d) shutdown
mode "$mode_system" {
    bindsym l exec --no-startup-id ~/.local/scripts/sway-exit.sh lock, mode "default"
    bindsym e exec --no-startup-id ~/.local/scripts/sway-exit.sh logout, mode "default"
    bindsym s exec --no-startup-id ~/.local/scripts/sway-exit.sh suspend, mode "default"
    bindsym h exec --no-startup-id ~/.local/scripts/sway-exit.sh hibernate, mode "default"
    bindsym r exec --no-startup-id ~/.local/scripts/sway-exit.sh reboot, mode "default"
    bindsym d exec --no-startup-id ~/.local/scripts/sway-exit.sh shutdown, mode "default"
    # back to normal: Enter or Escape
    bindsym Return mode "default"
    bindsym Escape mode "default"
}
```

which utilizes the script located in `~/.local/scripts/sway-exit.sh`

```bash
#!/bin/sh
lock() {
    swaylock -f -c 000000
}

case "$1" in
    lock)
        lock
        ;;
    logout)
        swaymsg exit
        ;;
    suspend)
        lock && systemctl suspend
        ;;
    hibernate)
        lock && systemctl hibernate
        ;;
    reboot)
        systemctl reboot
        ;;
    shutdown)
        systemctl poweroff
        ;;
    *)
        echo "Usage: $0 {lock|logout|suspend|hibernate|reboot|shutdown}"
        exit 2
esac

exit 0
```

### Notifications

In i3 I used [dunst] to handle notifications.
Unfortunately it's not [yet ready][dunst-264] to work with wayland.
I found [mako] to be a good replacement.  
Using `mako` is dead simple. 
After installation an additional line `exec mako` in the sway config file does the job.


### Printer

[CUPS][cups-archwiki] was not properly started after the switch.
What helped was to create the following configuration in `/etc/systemd/system/cups.socket`:

```ini
[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/var/run/cups/cups.sock
ListenStream=0.0.0.0:631
ListenDatagram=0.0.0.0:631
BindIPv6Only=ipv6-only

[Install]
WantedBy=multi-user.target
```

Then enable/start the service with `systemctl enable --now cups.service` and make sure it started properly:

```console
$ systemctl status cups.service
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-11-28 21:21:45 CET; 4min 31s ago
TriggeredBy: ● cups.socket
             ● cups.path
       Docs: man:cupsd(8)
   Main PID: 55543 (cupsd)
     Status: "Scheduler is running..."
      Tasks: 1 (limit: 19070)
     Memory: 5.2M
     CGroup: /system.slice/cups.service
             └─55543 /usr/bin/cupsd -l

Nov 28 21:21:45 mali systemd[1]: Starting CUPS Scheduler...
Nov 28 21:21:45 mali systemd[1]: Started CUPS Scheduler.
```

[i3]: https://i3wm.org/
[xserver]: https://en.wikipedia.org/wiki/X.Org_Server
[wayland]: https://en.wikipedia.org/wiki/Wayland_(display_server_protocol) 
[sway]: https://swaywm.org/
[sway-archwiki]: https://wiki.archlinux.org/index.php/Sway
[dunst]: https://dunst-project.org/
[dunst-264]: https://github.com/dunst-project/dunst/issues/264
[mako]: https://github.com/emersion/mako
[cups-archwiki]: https://wiki.archlinux.org/index.php/CUPS


Automate tasks with docker-compose and systemd

I have several tasks encapsulated in Docker containers which I need to trigger on a regular basis.
The scheduling can be done with systemd.
Both tools together have proven to be a quite powerful combination.

## Example: Backup service

Let's assume we have a backup service that lives in `/opt/backup`. 
This folder contains a `docker-compose.yaml` file which contains the configuration of a backup service.

We need one systemd unit for the service and one for the timer.
Both are shown below.
The setup is pretty straight forward. 

```ini
# /etc/systemd/system/backup.service
[Unit]
Description=Backup service
Requires=docker.service
After=docker.service

# Send mail in case of an error
OnFailure=status-email-user@%n.service

[Service]
WorkingDirectory=/opt/backup

ExecStart=/usr/local/bin/docker-compose up

[Install]
WantedBy=multi-user.target
```

```ini
# /etc/systemd/system/backup.timer
[Unit]
Description=Timer for backup service
Requires=backup.service

[Timer]
Unit=backup.service

# Time to wait after booting before we run first time
OnBootSec=10min

# Define a calendar event (see `man systemd.time`)
OnCalendar=*-*-* 03:00:00 Europe/Berlin

[Install]
WantedBy=multi-user.target
```

The service unit has a `OnFailure` hook which runs a separate systemd service in case the exit code of the service is non-zero.
This idea comes from the [Arch Wiki][archwiki-systemd-timers].  
The status email service can be configured in a generic way such that it can be re-used in other systemd services as well.

```ini
# /etc/systemd/system/status-email-user@.service
[Unit]
Description=Status Email for %i to user

[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email email@example.com %i
User=nobody
Group=systemd-journal
```

`/usr/local/bin/systemd-email`: 

```bash
#!/bin/sh

/usr/bin/mail -Ssendwait -t <<ERRMAIL
To: $1
From: Monitor (systemd) <alert@example.tld>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

$(systemctl status --full "$2")
ERRMAIL
```

Finally the timer needs to be started/enabled as usual:

```bash
systemctl start backup.timer
systemctl enable backup.timer
```

## Show logs

Logs can be read with `journalctl`:

```bash
journalctl -b -u backup.service
```

[archwiki-systemd-timers]: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement

Webcam Support in Arch Linux on Macbooks

I'm running [Manjaro Linux][manjaro] (an [Arch Linux][arch] derivative) on my MacbookPro12,1 (Retina, 13-inch, Early 2015).

![Image source: support.apple.com, 2020/04/01](/posts/<post_slug>/macbook-pro.png)

I was astonished how many things just worked out-of-the-box.
Kudos to the Arch and Manjaro teams for their great work!

Unfortunately one thing that did not work out-of-the-box is the webcam.
It requires a driver that is not part of the official kernel but must be installed separately.  
The code is in the [Arch User Repository (AUR)][arch-aur].
I use [yay][yay] to install packages from AUR which I can highly recommend and which I will use in this article.

Let's get our hands dirty!

First let's get information about all installed kernels and see if the headers are installed for all of them:

```console
$ pacman -Q | grep -E 'linux[0-9]+'  # see which kernels are installed
```

For each installed linux kernel there should be a `-headers` file next to it, e.g.

```
linux419 4.19.113-1
linux419-headers 4.19.113-1
linux54 5.4.28-1
linux54-headers 5.4.28-1
linux55 5.5.13-1
linux55-headers 5.5.13-1
```

If the headers are missing, make sure to install them:

```console
$ yay -S linux-headers   # select the headers that are missing
```

Then let's get the [driver][bcwc-pcie] and install it from AUR:

```console
$ yay -S bcwc-pcie-git
```

After the installation we need to load the kernel module:

```console
$ modprobe facetimehd
```

You can test if the video source has been identified correctly by executing `v4l2-ctl --list-devices`.
If everything worked out, the output should be:

```
Apple Facetime HD (PCI:0000:02:00.0):
	/dev/video0
```

If the output is instead `No /dev/video0 device`, then make sure to unload the kernel module `bdc_pci` as described in the [wiki][bcwc-pcie-wiki].
This can be done by running the following commands:

```bash
modprobe -r facetimehd  # temporary remove facetimehd module
modprobe -r bdc_pci     # remove disturbing kernel module

# make sure that the disturbing kernel module is blacklisted
# and cannot be loaded as a dependency of another module.
echo "blacklist bdc_pci\ninstall bdc_pci /bin/false" > /etc/modprobe.d/bcwc-pcie.conf

modprobe facetimehd     # load the facetimehd module again
```

The webcam should work now.
You can test it on any website that requires a webcam, such as [meet.jit.si][jitsi].
Have fun!

[manjaro]: https://manjaro.org/
[arch]: https://www.archlinux.org/
[arch-aur]: https://aur.archlinux.org/
[yay]: https://github.com/Jguer/yay
[bcwc-pcie]: https://aur.archlinux.org/packages/bcwc-pcie-git/
[bcwc-pcie-wiki]: https://github.com/patjak/bcwc_pcie/wiki#known-issues
[jitsi]: https://meet.jit.si/


OfflineIMAP + systemd timer

I use [mutt] to manage my emails and access them from the terminal.
To sync the mails between the IMAP server and mutt I use [OfflineIMAP].

To regularly check for new mails I use a [systemd timer][systemd-timer].
The necessary files can be found [in the official repository][offlineimap-systemd].

Let's clone the repository first and copy all necessary files to `/etc/systemd/user`.

```bash
cd /tmp
git clone --depth 1 git@github.com:OfflineIMAP/offlineimap.git  # a shallow copy is enough
cd offlineimap/contrib/systemd
sudo cp *.{service,timer} /etc/systemd/user/
systemctl --user daemon-reload
cd /tmp && rm -rf /tmp/offlineimap
```

By default the update interval of the timer is set to 15min.
I preferred an update interval of 5 min, which can be easily accomplished.

```console
$ systemctl --user edit offlineimap-oneshot.timer
```

In this file values can be overwritten as such:

```ini
[Timer]
OnUnitInactiveSec=5min
```

Finally it's time to enable and start the timer.

```console
$ systemctl --user enable offlineimap-oneshot.timer # autostart at boot
$ systemctl --user start offlineimap-oneshot.timer  # start now
```

Let's check if the timer is up and running.
`systemctl --user status offlineimap-oneshot.timer` should show that it is up and running and tell how many time is left until the next run:

```
● offlineimap-oneshot.timer - Offlineimap Query Timer
     Loaded: loaded (/usr/lib/systemd/user/offlineimap-oneshot.timer; enabled; vendor preset: enabled)
    Drop-In: /home/dotcs/.config/systemd/user/offlineimap-oneshot.timer.d
             └─override.conf
     Active: active (waiting) since Wed 2020-04-01 16:27:20 CEST; 8min ago
    Trigger: Wed 2020-04-01 16:37:34 CEST; 1min 55s left
   Triggers: ● offlineimap-oneshot.service
```

[mutt]: http://www.mutt.org/
[offlineimap]: https://www.offlineimap.org/
[offlineimap-systemd]: https://github.com/OfflineIMAP/offlineimap/tree/master/contrib/systemd
[systemd-timer]: https://www.freedesktop.org/software/systemd/man/systemd.timer.html

i3 + termite + custom themes = <3

I love the sun – especially in Spring when temperatures are not too hot and taking a sunbath is a real pleasure. And I love working in the sun, which is often a challenge because of the poor contrast - especially if, like me, you like to use dark themes.

Since I recently changed to [i3] as my window manager, I use [termite] as my default terminal which has by default no simple way to switch themes – at least not to my knowledge. But working in the sun requires a light theme, so I decided to work on a simple theme changer that is also integrated in i3.

So let's get to work.

First we need custom color themes. I have taken the two themes from [this GitHub repository][termite-solarized] and put them in `~/.config/termite/themes`.
Of course you can also define custom themes and put them there. The theme files should have the following format:

```ini
[colors]
foreground = #000000
background = #ffffff
# and so on
```

Then copy your current `~/.config/termite/config` to `~/.config/termite/config.base` and remove the `colors` section.

We will now need a way to append a theme file to the `config.base` file. I've created a simple script that does this job:

```bash
#!/usr/bin/env bash

USAGE="$0 light|dark"

TERMITE_CONF_FOLDER=~/.config/termite
THEME=$1

change_theme() {
    echo "# THIS FILE HAS BEEN AUTOGENERATED. DO NOT CHANGE MANUALLY!" | \
        cat - /tmp/termite-switch-theme.hint $TERMITE_CONF_FOLDER/config.base $TERMITE_CONF_FOLDER/themes/$1 > $TERMITE_CONF_FOLDER/config
    killall -USR1 termite || true
}

case $THEME in
    light|solarized-light) change_theme solarized-light ;;
    dark|solarized-dark) change_theme solarized-dark ;;
    *) echo $USAGE ;;
esac
```

Put this script somewhere and make it executable. In my case I've saved the file in `~/.local/scripts/termite-switch-theme.sh`. You should be able to switch themes now by calling the script, e.g. `~/.local/scripts/termite-switch-theme.sh` light.

This is already great, but for a perfect integration with i3 put these lines into your `~/.config/i3/config`:

```
set $mode_term_theme Terminal theme (l) light, (d) dark
mode "$mode_term_theme" {
    # choose which theme should be applied by pressing l (light) or d (dark)
    bindsym l exec --no-startup-id "~/.local/scripts/termite-switch-theme.sh light", mode "default"
    bindsym d exec --no-startup-id "~/.local/scripts/termite-switch-theme.sh dark", mode "default"
    # back to normal: Enter or Escape
    bindsym Return mode "default"
    bindsym Escape mode "default"
}
bindsym $mod+t mode "$mode_term_theme"
```

Finally reload the i3 config with `mod+shift+c`. Now you can change themes with `mod+t` and choose which theme should be applied (light or dark). All running terminals will immediately reflect your theme changes. Have fun!

## Base16 Themes

If you want to have even more themes to choose from take a look at the wonderful repository [khamer/base16-termite][base16-termite]. Those themes are working out-of-the-box just as described above.

## Acknowledgements

- Thanks to [@BarbUk][github-barbuk] for [helping me find the correct signal][termite-issue-730] to send to running termite instances.
- Thanks to [@nils-braun][blog-nils-braun] for reviewing this article.

[i3]: https://i3wm.org/
[termite]: https://github.com/thestinger/termite
[termite-solarized]: https://github.com/alpha-omega/termite-colors-solarized
[base16-termite]: https://github.com/khamer/base16-termite
[github-barbuk]: https://github.com/BarbUk
[termite-issue-730]: https://github.com/thestinger/termite/issues/730
[blog-nils-braun]: https://nils-braun.github.io/


Spotify Desktop App with HiDPI Scaling in GNOME 3

When using a HiDPI screen, such as the MacBook Pro with Retina display, Spotify Desktop may not automatically detect the correct scaling factor.
I have noticed issues in my Manjaro installation that runs with GNOME 3 Desktop.
Spotify has been installed from the AUR package repository.  
The wrong scaling factor leads to very small font size that is hard to read.

```console
$ spotify --version
Spotify version 1.1.10.546.ge08ef575, Copyright (c) 2019, Spotify Ltd
```

Fortunately there is an option to force Spotify Desktop to use a (hardcoded) scaling factor.
Use the following command and vary the scaling factor in order to find the correct factor first:

```console
$ spotify --force-device-scale-factor=2
```

After the correct value has been found, adjust the desktop entry that GNOME uses to when starting the application via its launcher.
The file lives in `/usr/share/applications/spotify.desktop`:

```ini
[Desktop Entry]
Type=Application
Name=Spotify
GenericName=Music Player
Icon=spotify-client
TryExec=spotify
Exec=spotify --force-device-scale-factor=2 %U
Terminal=false
MimeType=x-scheme-handler/spotify;
Categories=Audio;Music;Player;AudioVideo;
StartupWMClass=spotify
```


An "open" command in Linux

As a previous macOS user I am used to call `open <anything>` in a terminal to open the current file or folder with the standard tool.
So `open .` would open the current folder while `open file.pdf` would open the PDF in the default PDF viewer.

Today I learned that `xdg-open` serves the same purpose on the Linux desktop. So I configured an alias, to have the same behavior on both systems: 

```bash
alias open="xdg-open &>/dev/null"
```

## Query and set defaults

`xdg-open` is part of [`xdg-utils`][archwiki-xdg-utils], which [describes itself][freedesktop-xdg-utils] as

> xdg-utils is a set of tools that allows applications to easily integrate with the desktop environment of the user, regardless of the specific desktop environment that the user runs.

It's super convenient to change the default application for a given file, say a PDF.
Let's change the default program:

First let's assume we don't know the mime-type of the PDF, which is `application/pdf`.
We can find this type by query all known filetypes:

```console
$ xdg-mime query filetype /path/to/a/file.pdf 
application/pdf
```

Let's see which default application is currently configured for this filetype:

```console
$ xdg-mime query default application/pdf
chromium.desktop
```

If we don't want to use chromium to read PDFs, but for example [zathura] we can change the default application as follows:

```console
$ find /usr/share/applications/ -name '*zathura*'
/usr/share/applications/org.pwmt.zathura-pdf-mupdf.desktop
/usr/share/applications/org.pwmt.zathura.desktop

$ xdg-mime default org.pwmt.zathura.desktop application/pdf

$ xdg-mime query default application/pdf
org.pwmt.zathura.desktop
```

Now PDF files are opened with zathura when using our new `open` command as defined above.

A lot programs bring their own `.desktop` file(s). Files are listed in `/usr/share/appliations` and can be overridden or suplemented with files located in `~/.local/share/applications`. The specification of those files [can be found here][freedesktop-desktop-entry].


[archwiki-xdg-utils]: https://wiki.archlinux.org/index.php/Xdg-utils
[freedesktop-xdg-utils]: https://freedesktop.org/wiki/Software/xdg-utils/
[zathura]: https://pwmt.org/projects/zathura/
[freedesktop-desktop-entry]: https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys

GNOME 3: Change wallpaper periodically

If you are using GNOME 3 and you want to periodically change your desktop background using images in a folder, this is for you.

Put this script somewhere and make it executable.

```bash
#!/usr/bin/env bash

# You need to adjust this path
WALLPAPER_FOLDER=/path/to/your/wallpaper/folder

# https://askubuntu.com/a/1073769/277761
PID=$(pgrep gnome-session | tail -n1)
export DBUS_SESSION_BUS_ADDRESS=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/$PID/environ|cut -d= -f2-)

FILE_PATH=`ls $WALLPAPER_FOLDER | shuf -n 1`
FILE_URI="file://$WALLPAPER_FOLDER/$FILE_PATH"
/usr/bin/gsettings set org.gnome.desktop.background picture-uri $FILE_URI
```

Then create a cronjob that executes this script periodically, e.g. by using this line:

```
*/10 * * * * /path/to/your/file.sh
```

And you're done. Have fun!

Generic tag that I use to tag (short) blog entries, in which I mainly document stuff for myself but expose those notes as they might be of interest for others as well.


Tag: notes