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.
Neovim has some nice additions like honoring the blinking cursor from
kitty when in insert mode. I don't remember why I used vim instead of
neovim here, but neovim is mature enough that it should be an excellent
choice to use for many years to come.
I originally made this change to take advantage of wpgtk, and although I
was successful and wpgtk was a cool experience, I am not that interested
in updating all my config files to use wpgtk instead of wal.
Since this was mainly useful for thunar and nautilus, and since I'm
considering using ranger only and writing my own scripts for additional
functionality, I may change this to a simpler theme in the future.
This makes polybar less obtrusive, however I've been considering
removing it in the long-term to maximize screen estate. Although polybar
is cute, I don't *need* to know everything in the bar every second I use
the computer. Having specialized commands or keybinds that show certain
information seems more useful in this case.
Some information, such as the date and time, could become a part of the
wallpaper itself, making blank desktops more useful than they are now.
Although widgets are also an option, I have not verified how well these
work under my current setup yet.
This makes dealing with certain Japanese files significantly easier
since we no longer have to worry about manually performing a Shift JIS
to UTF-8 conversion before opening the file in vim, nor do we have to
worry about manually changing the encoding with :e ++enc=sjis.
This makes dealing with CJK files inside vim a much more pleasant
experience. Note that automatically handling Shift JIS encoded files is
something I haven't implemented yet, although a simple keybind could
make things more manageable.
This was an experiment to see if I could make switching between desktops
easier. Instead of thinking about desktops in terms of their contents or
numbers, we can think about them in terms of gestures used to reveal
them.
The main advantage to this setup is that you can access any of the other
desktops with one keystroke. This is in contrast to having to press
super+tab twice. The other advantage is that the desktops are always at
a predictable location. One swipe to the right will always get you the
desktop on the right, whereas two super+tabs can land on any desktop.
This appears to fix an issue where the screen would occasionally flicker
after resuming from dpms' screen blanking feature. So far I have not
observed any significant performance degradations.
Reference: https://github.com/yshui/picom/issues/578
A verbosity level of 2 was cool during testing, but now that the
Makefile has been stable for years at this point, having all that
verbosity seems unnecessary. This change still shows when things are
stowed, but with less detail than before.
As far as I can tell, dual-function-keys also works in a tty, so
keystrings is no longer necessary, and you don't have to worry about
making sure that loadkeys is ran either.
