Now that I understand more about how GNU/Linux distributions, display
managers, and X sessions work, it makes sense to separate meta packages
based on environment used.
When you use a display manager, you're just starting X in a fancy way.
Since you can run any program you want on the X server, it is easy to
install multiple desktop environments on the same machine and switch
between them easily, provided your setup is adequately modular (which
it should be by default).
Instead of manually setting the DPI to 192 or other values, we can
just take the value from xrdb instead.
This script, in combination with GTK's settings.ini if you are in a
non-GNOME environment, is everything you need to launch both GTK and
Qt applications at the appropriate DPI, with their respective themes
applied as well.
Instead of relying on a fish function to configure neofetch,
we can use config.conf instead.
Since neofetch is an independent program, we also make a new stow
package for it, instead of relying on the fish config being present.
Since I now know how GNOME works (using dconf and gsettings), changing
settings manually with GNOME Tweaks is no longer necessary. Instead,
everything can be handled directly through the `make rice` command.
It turns out that compton has received many bugfixes and improvements
since the last time I used the fading effect. It is a nice animation
that adds a bit of spice to the desktop, so I've enabled it for now.
It turns out that GDK_SCALE and GDK_DPI_SCALE is what you need to add
HiDPI support to GTK applications. Since you probably have .Xresources
adjusted for your HiDPI display, you will need to set both GDK_SCALE and
GDK_DPI_SCALE at the same time to render things properly.
Ironically, I never got this to work before. Maybe because I was always
using 'GTK_SCALE' instead of 'GDK_SCALE', or maybe because I never used
both GDK_SCALE and GDK_DPI_SCALE at the same time.
This gives me full HiDPI support in bspwm, with the exception of a few
applications (polybar, dunst) that don't honor DPI as of this writing.
Since the Adapta theme isn't maintained anymore, some problems in newer
versions of GNOME (such as incorrect padding for text underlines in
Nautilus) cannot be reported since issues are disabled.
It turns out that Arc-Dark does have padding, I just wasn't scaling GTK
applications properly. Since I already use the Arc theme for KDE, using
it for GTK as well gives all my desktop applications a universal look
and feel.
The solid variant is used instead of the original to remove the
transparent effect seen in Nautilus. The Arc GTK theme supports both
light and dark color schemes, which is very nice.
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
