It's the end of an era and I no longer use bspwm. Although the tiling of
bspwm was admittedly cool, at the end of the day most of my time isn't
spent opening new windows so working with the i3-like sway instead works
just fine.
Having a meta package was cool and it got the job done, but it's
inconvenient to use when adding and removing a lot of packages.
One alternative I'm looking at is simply keeping track of all the
explicitly installed packages and storing that in a text file. This
makes it easy to keep track of all the installed packages without
introducing downsides, and new machines that don't need certain
packages can simply delete those lines.
As of now I am largely uninterested in customizing neofetch to look
completely different, although time will tell if I stay true to this
stance. As of now, however, showing an image is enough.
Over time compton became unmaintained and a replacement package picom
took its place. After trying out sway for a bit, I realized that it
doesn't need a separate compositor at all like bspwm does, so I might
just switch to it. Note that there is a performance penalty on sway
that I haven't figured out how to solve yet.
evince actually uses less memory than zathura and seems to be more
efficient overall, although it isn't as customizable as zathura and
not as minimal in terms of UI.
Overall, I'd rather just use zathura, which also lets me be more
consistent in my bspwm setup.
Apparently gnome-books and sushi depend on evince, the first of which
is a GUI for djvu/epub files and the second of which lets you preview files
with the spacebar in the file explorer. Ironically, I've never used this
feature until I read about it, and although it seems cool, I don't think
I have a use for it as I've been opening my files normally for years now.
Some of these settings, specifically the window-status ones, produced
error messages in more recent versions of tmux. I've gone ahead and
simplified everything to the default colors since they work pretty well
already.
These packages aren't included by default anymore so adding them here
makes sense. Note that maintaining a large meta package is actually
difficult since one error means the whole thing doesn't work.
I am looking for an alternative solution to keep things somewhat
automated while at the same time increase flexibility when it comes
to the initial setup.
I actually wrote this in 2018 but never committed it. Might as well do
that now. The extensions it installs are uBlock Origin, Vimium, and
HTTPS Everywhere.
I wanted to commit some more stuff for 2020. Better late than never,
right? The most significant change is probably in fish_prompt.fish.
I fixed an edge case where the directory in question could be the
same as the user's username.
This abbreviation is useful when you change your color scheme with
wal and plan to or have multiple kitty windows open (since kitty
itself will still be using the color scheme it initially loaded
from the config file).
Since animated desktop backgrounds are more of a hassle to maintain than
they are worth, I've gone ahead and removed xwinwrap. If you are running
bspwm and still want an animated desktop background, use:
xwinwrap -g 3840x2160 -ov -- mpv -wid WID --loop inf your.video
For reference, you can use xwinwrap with any resolution you want, not
just your screen size. mpv will also accept pretty much any animated
format out there.
Since most of the README wouldn't be relevant to most users anyway,
I've gone ahead and removed it. In the future I may consider writing
a brief guide on how to set up certain things, but for now I'm focusing
more on the dotfiles and bootstrap aspect itself instead of trying to
treat everything as a collective whole.
It turns out that using a literal dot instead of the word dotfiles has a
negative impact on the discoverability of the repository. Since the
directory name can be changed to .files when running `git clone`, this
gives us the freedom to name the repository however we please.
This *should* complete the process of adding full variable DPI support
to an X session. The X DPI is now set dynamically and changes on
resolution change, making this setup easy to deploy to both traditional
and HiDPI environments.
This caused some problems when the ~/.Xresources DPI was 192 and the
screen resolution was 96 DPI. Since I now know how to manipulate cursor
size even after X is started, manually setting Xft.dpi in ~/.Xresources
to 96 or 192 DPI is no longer needed.
Now that I figured out how to change cursor size for all applications
and not just a select few, restarting the X session to use a new cursor
size is no longer necessary.
