xeventbind is a useful program that lets you run any command on
resolution change, similar to how GNOME on Wayland is able to change
scaling on on resolution change, but not exactly.
Since we're still using X, existing programs are not affected; they
have to be restarted instead.
This commit adds full variable DPI support to polybar. This means that
it is possible to use the same polybar setup on both a traditional and
HiDPI display.
Additionally, font size has been slightly adjusted since polybar does
not support decimal font sizes. Some other numbers have also been
changed.
It turns out that neofetch works exceptionally well with this terminal
size, so I'm making it the default in kitty.
Now I can use neofetch without having to worry about resizing the
terminal window for the desired effect.
For software development and other practices where distinguishing
between the colors in a color scheme is important (e.g. red versus
green, etc.) the base16-tomorrow-night theme offers a great middle
ground between aesthetics and readability.
It turns out that 'window' (as of this writing) does not work very well
when trying to use it as an alt-tab replacement. It's simply easier to
just use the functionality provided by your window manager instead.
I have never used rofi's 'run' feature, since any time I'd need to run
a command I'd just do it from a terminal, which also lets me see any
output from that program as well.
Note that window order is not based on the order in which windows are
hidden, but something else entirely. For this reason, it is recommended
to hide only one window at once.
A more robust solution would be to let the user choose from a list of
available hidden windows, potentially through rofi's dmenu capability.
Instead of managing these variables at the bspwm level, we can simply
use rofi instead. This means that applications can be launched in other
desktop environments with the correct settings applied through rofi.
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).
