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.
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.
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.
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.
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.
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.
These are obsolete technologies that are no longer needed thanks to
dual-function-keys, which I'll add in a future commit. This also fixes
an issue where left control would behave like an escape key when tapped,
which caused a lot of accidental escapes.
I am personally not amused by some of the defaults that firefox ships
with and would rather not have to deal with them on new configurations.
Although it's possible to sync settings across devices or simply copy
the profile directory, the advantages of librewolf outweigh the cons for
my individual use case, at least for now.
Since I usually have a browser and terminal emulator open most of the
time, I have placed them back as desktop 1 and 2 by default. I'm used to
the file browser being in 3, and 4 serves as media, which is important
for language immersion in particular.
The other 6 icons are numbers for individuals that know how to read
other languages.
One of the conveniences of GNOME is auto-mounting. Although manually
mounting is a good learning exercise, we can improve productivity by
auto-mounting by default.
This makes working with bspwm a lot cooler since the cursor is now
automatically hidden when not in use, making full screen videos and
other applications a lot more immersive.
Note that although it's possible to make fcitx work with alacritty as
well, the current implementation doesn't show what you're typing as
you're typing it, which is inconvenient.
Because of this, I recommend using kitty in all cases if switching input
methods is important for your use case. kitty also has the advantage of
image preview support on both xorg and wayland, since ueberzug does not
have wayland support.
Note that I previously set up a working environment with ibus-mozc
which, although was cool (and better than ibus-anthy), did not offer all
the benefits that fcitx provides. Now that I figured out how to make
fcitx work on both xorg and wayland, as well as in applications like
anki, this is my preferred input method for personal systems.
We actually still need compton (now picom) for screen tearing in bspwm,
so we'll add it back now. In the future it may be useful to keep
dotfiles in the repository even when I no longer use them, since the
configuration itself may still be useful.
I like how sway handles workspaces. This change makes it so bspwm uses
numbers as the workspaces and polybar only shows workspaces that are
being used in the bar.
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.
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.
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.
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.
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.
