Realistically won't be using custom backgrounds with kitty due to the
complexity involved in changing them among other things. Setting the
background opacity and letting the desktop environment manage the
background instead is more convenient.
Having image diffs in the terminal is very cool, however I ultimately
decided against using kitty's diff feature due to using the existing
colors of the shell being non-trivial.
This makes it easier to see the most relevant results first without
having to scroll up, assuming there are enough results where scrolling
up was necessary.
This added a toggleable bar similar to polybar, except this time it
showed the open applications at the bottom. I eventually switched to
GNOME, which is able to achieve this and much more with dash-to-panel,
an extension that has been steadily improving over the years.
Since I use GNOME now, dunst isn't needed, although I feel like the
dunst notifications looked cooler than the GNOME ones since they also
followed the color scheme of the environment.
I never used this key and I don't think I ever will. feh is a great
image viewer that's simple, fast, and anti-aliases things properly,
although I believe there's a high probability that another image viewer
is out there that nails all the boxes and then some.
I personally found this to be a stunning blur that I would love to use
in GNOME, however I am okay with using GNOME without it due to the many
benefits GNOME provides.
Although it was cute that I was the only one that knew how to use my
computer, standard keybinds is a pretty neat thing to have. This was
another change I programmed before deciding to use GNOME instead.
Although I am glad I eventually found a fix for this, it's much easier
to simply use GNOME with extensions and not have to worry about hacks
like these. If by chance such GNOME extensions are as hacky as the
solution in this commit, I'd argue that the convenience of those hacks
being abstracted away from the user outweighs fixing things manually.
Instead of restricting myself to 4 desktops, I eventually decided on a
setup where desktops would be dynamically created as applications were
opened. I then realized what I was doing was replicating the GNOME
desktop environment in a much less efficient way, and eventually
switched from bspwm to GNOME.
At some point I added libinput-gestures to my setup to replicate the
touchpad gestures I loved so much on GNOME. Although this was cute, such
gestures lacked the animations from GNOME and would even stop working
entirely from time to time. It is for this reason that I created a keybind
specifically to reload libinput-gestures.
For history's sake, I'm including how I changed the color scheme of
tint2 with wal. Note that I don't use tint2 anymore since I realized
that what I was trying to do with tint2 can already be achieved much
easier and much more polished with GNOME extensions.
These are old changes I made while I was still using bspwm. Although
bspwm is an amazing window manager, I feel like the simplicity of GNOME,
as well as how customizable it can be, negates any potential benefits
one can achieve with bspwm and its vast configuration possibilities.
As one example, alttab is a cool piece of software that brings the
concept of alt-tabbing to window managers like bspwm, however, GNOME is
already capable of doing this and does so in a more elegant way, showing
views of the windows you're alt-tabbing between.
Although this was cute and allowed us to open links in any browser from
anywhere on the computer, in practice this "ability" wasn't that useful.
In the event that looking up words is needed, it's easier to open or
switch to qutebrowser and use its search feature instead of trying to
remember which keybinding is which.
One solution for the future would be to synchronize qutebrowser search
engines with a rofi/dmenu-like selection screen, which would solve the
problem of not remembering which keybind is which. Frequently used
search engines would be higher on the list and would require less or no
typing beyond <CR> after the initial prompt.
Since we often use non-monocle layouts without borders or gaps, having a
separate borderless/gapless monocle mode was often confusing since we
didn't know which layout we were in. When using a status indicator with
bars like polybar, knowing the current layout required a separate script
and was overall hacky, with its state not being updated until certain
bspc events occurred.
Browsers were always a pain point for me due to the manual intervention
they often required to get extensions configured properly across
separate user profiles. qutebrowser has improved significantly since the
last time I tried it (around 2017) and supports modern browsing due to
its usage of Chromium 102 with QtWebEngine 6.4.0.
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.
alttab <https://github.com/sagb/alttab> is a cool alternative to the
more traditional ways of managing windows in bspwm that lets us focus on
the currently open windows instead of which desktop they're on.
Note that I originally used this as a test to see how useful it would
be, however I quickly realized that having unpredictable desktop states
is not ideal, especially when not using a status bar like polybar.
The code was shared as a solution to a post on r/bspwm. Credits to the
original author, however I plan to ditch this solution for more
predictable desktop management.
It turns out polybar was bloat and I don't actually need one, at least
that's my current thought process. In particular the advantage of
fullscreen windows without having to worry about whether polybar is
visible or not should outweigh when I temporarily show the bar with a
keybind.
Note that while I was exploring taking advantage of bspwm's monocle
layout more, I went through a point where borders would only be visible
when multiple windows were present, which required me to use the single
monocle config variable and implement the solution proposed in the
GitHub issue below:
https://github.com/polybar/polybar/issues/1880#issuecomment-674518936
I used thunar for a while and it was a great experience with few
exceptions, however I will likely remove it in favor of a more command
line-based experience. Using thunar was a valuable learning exercise and
it helped me understand more about what file browsers actually do, and I
realized that I can replicate this experience fairly trivially while
giving me the benefits of my existing configuration.
This makes it easier to manage mpv windows like all other windows, which
lets us take advantage of watching 16:9 videos with mpv tiled while
working on other things.
