It turns out that some software will not render properly if the DPI is
not set using increments of 25% (i.e. 96, 120, 144, 168, 192, etc.).
Since GNOME and Plasma already use a scale factor of 2x, it makes sense
to use 2x for .Xresources as well. Now GTK and Qt applications should
share the same size across both bspwm and their respective DEs.
It turns out that desktop environments like GNOME and Plasma will
re-write the GTK settings.ini regardless of whether or not it is
actually used. To avoid diffing issues, I've gone ahead and replaced
my commented settings.ini with the one formatted by KDE Plasma.
Note that the current settings.ini file consists of all the settings you
need in a modern GTK environment. Be wary of programs that attempt to
add legacy options to this file, such as kde-gtk-config.
Here I commit the addition of VerbosePkgLists for reference. It turns
out that yay's package upgrade list looks significantly better than
pacman's VerbosePkgLists (and is a lot more legible).
Since pacman will not use VerbosePkgLists when the number of terminal
columns is low enough, it makes sense to simply use the default setting
instead.
vs-wal has some issues such as illegible text and no live reloading,
however, it is (from what I know) the easiest way to use a color scheme
consistent with your setup.
Code will use the default dark theme if vs-wal is not found.
Since my dotfiles are now sorted by individual programs instead of in
groups, I'm trying a new README format. This format should provide more
useful information and be easier to read as well.
Since kitty would automatically assume a fullscreen or half screen size
as the default, it's much easier to simply specify the size all floating
windows should start out as.
Since kitty allows specifying the size in cells instead of pixels, it
is easy to achieve the same "actual" terminal size regardless of which
DPI is being used.
It turns out that placing similar config files (i.e. bspwm-related) in
the same directory is not the way to go about handling dotfiles since
each config file (or dotfile) *should* manipulate only a single program.
This was not the case back when I used urxvt (which would require the
old method of .Xresources), but now that I understand more about how
*modern* dotfiles work (with $XDG_CONFIG_HOME), separating dotfiles by
program became the obvious choice.
Instead of running two systemctl commands (start and enable),
one can simply use `systemctl enable --now` instead.
The grub command was removed since I never used it and haven't
found a need to do so.
Now that I've learned kitty, other terminal emulators like termite and
urxvt are no longer necessary. Here I remove any config files that were
necessary for either termite or urxvt and change all terminal options
to kitty.
As an added bonus, a global gtk.css file is no longer necessary. This
contradicted a core idea of dotfiles (that every program should have
its own directory in $XDG_CONFIG_HOME) and was in general a weird hack
that also affected non-termite emulators.
It turns out that kitty has support to change all of its colors
independently from the current terminal with a simple command. This
was the only issue I had with making pywal and kitty work together,
so I'm glad I found it.
Additionally, kitty supports DPI changes immediately (at least with
xrdb). There is no need to detach a session and open a new terminal
since kitty will handle DPI changes automatically, compared to other
terminals like urxvt, which would require a new instance. Even then,
the border padding for urxvt is not adjusted to the new DPI; kitty
is simply the way to go if your monitor setup is non-trivial.
As a side note, the kitty documentation is very good. I highly
recommend reading it if you plan to use kitty (which you should).
Instead of "hiding" dotfiles in an extra group, it is easier to use
separate packages for each unique set of files. Since I'm working on
making my setup more modular, and since I can stow all my dotfiles with
a single command anyway, this configuration is more appealing now.
I removed termite before, but this time I shouldn't need to add it
again. The kitty terminal emulator supports image output and handles
fonts better than termite. Plus, true transparency can be used without
sacrificing images in the terminal.
Since the wal color scheme is not installed until PlugInstall is ran,
the colorscheme function will always throw an error that needs manual
intervention. This fixes that.
Since sudo times out after 5 minutes, and since we don't want to run
every command as root, we can instead create a "persistent sudo" by
invoking the sudo command at least once within 5 minute time frames.
This script does just that, and solves the problem of sudo timing out
after a long command.
It turns out that since tmux sessions will stay active after you close a
terminal window, it is easy to end up with a lot of empty sessions. This
makes it difficult to detach and re-attach the appropriate tmux sessions.
Additionally, some features of kitty (notably terminal images and
dynamic background opacity) will not work inside tmux. Since kitty has
its own window manager, this caveat can be easily circumvented. By
invoking tmux manually instead, we also avoid the problem of nested
tmux sessions.
Since changing the default shell to fish without breaking Fedora with
GNOME is non-trivial, I instead set the option from the terminal
emulator itself.
Although this won't carry over to ttys and other environments, it should
be simple enough to start fish manually when needed.
Since the community package doesn't include the fish completions found
upstream, we install them here instead. There is already a bug report
about the fish completions, and when it eventually gets fixed, these
steps can be removed from the PKGBUILD.
Bug report: https://bugs.archlinux.org/task/55786
Since dotfiles only change the functionality of existing programs, it is
reasonable to stow everything at once for consistency between operating
systems.
Although there's already a default terminal emulator, configuring it
through dotfiles is non-trivial. kitty works exceptionally well on
Fedora, and since I already use it on Arch Linux, I might as well
use it here too.
Instead of installing a pre-built RPM, we can build it ourselves on the
spot instead. This is less maintenance for me and makes it easier to
verify the package being installed.
This should work, but it hasn't been tested yet. In the future I'd like
to use branches before pushing large updates to master. This would also
give me the chance to see how symlinks behave when a different branch is
checked out.
