rofi was cute, however I no longer have a desire to run an external
interface for simply starting programs. This can be achieved in many
different ways through a shell, and without the disadvantages (such as
having all items listed by default) that rofi came with.
This was cute, however knowing which desktop we're on may be irrelevant
in a future workspace implementation. Adding this information to the
fish prompt with starship may also be an option.
This makes rofi work nicely with multi-monitor setups, however I was
planning to remove rofi since I can do everything that rofi can do with
a simple shell, and without having to worry about its inconveniences,
such as unreadable default wal color themes.
This was cool when we had KDE-specific applications, but since I'm
prioritizing ranger and nautilus now, dolphin isn't needed. Since I'm
focusing heavily on terminal and web-based applications, there is less
need to customize KDE applications specifically.
Two other advantages to this is that I no longer have to manually update
the colors in kdeglobals, and most if not all of the environment can be
programmatically set up with minimal effort.
Although rofi-calc was certainly cool to use, it is not in the
official repositories. Instead of trying to rely on it as a
dependency, I've gone ahead and removed it instead.
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.
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.
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.
