Since padding-left and padding-right will always be the same in this
case, I've gone ahead and made it simply "padding".
Since keys can use the values from other keys, some duplication in the
module sections can be avoided.
Since launch.sh calculates all the bar values for us (as well as bspwm
settings), we can simply store the top_padding value in the user's cache
directory, then reference that number within sxhkd.
This way, if the top_padding value is changed through launch.sh, editing
sxhkdrc manually isn't needed, and the config file doesn't need to be
reloaded.
Although width can also be found through xrandr, it felt a bit messy to
parse output that wasn't meant to be parsed by other programs.
Since I can guarantee that the user will have bspwm (and not xrandr)
installed, I decided to use bspc instead. The current setup only works
for one monitor, but it should be relatively painless to setup multiple
monitors in the future (assuming they share the same dpi).
Since polybar supports include files, we can generate part of the bar
config with launch.sh and store it in $HOME/.cache. Since launch.sh is
a shell script, and since bspc is an interface to bspwm, we can also
change the necessary window manager settings required for different
bars, or even configure the settings for no bar at all.
A future implementation of launch.sh may allow us to change polybar
dimensions based on current resolution and whether the screen is HiDPI
or not, although it probably won't be *too* fancy since I don't need to
support every potential DPI a user may have.
Alternatively, someone could submit a patch for polybar to make it
DPI-aware. This is the ideal solution since the bar would be scaled
naturally based on dpi, instead of having to manually halve things
ourselves.
Maybe this is a new feature of polybar, or maybe I've never read the
documentation thoroughly enough. This commit adds inheritance for my
floating bar and top bar, so that duplication isn't necessary.
This makes things a lot easier to see and understand. There is also a
way to include other files, which may be useful for automatically
generating key value pairs for polybar based on screen resolution.
It may also be used to set different variables (i.e. colors) based on
which bar is used. Pretty handy.
Now that I understand the difference between the monocle desktop
layout and the fullscreen state of a node, it became clear that I
would probably use both.
Since I use the single_monocle config option, desktops with the
tiled layout may contain a monocle node, so I needed a way to tell
which layout a desktop was running.
I initially thought about using sxhkd to send a notification with
the layout portion of bspc query -T -d, however polybar supports
showing the layout natively, so I don't need to use a keybind.
The layout portion of the polybar config may not be needed if, for
example, you decide to disable single_monocle and there is no ambiguity
between fullscreen nodes and monocle desktops.
pywal (also known as wal) lets us change color schemes with a cache
directory instead of editing config files directly. This helps us
separate the dotfiles from the color schemes.
This commit removes explicit color settings from my dotfiles, which are
now managed by pywal. Dunst has been added to show any notifications
that I may want to use in the future. The colors.Xresources file is used
to prevent urxvt from using a depth of 32.
My custom colors.vim file has been removed in favor of wal.vim, which
solves some problems I had to manually resolve myself and should make
things easier to maintain in the long term.
Note that pywal also supports base16 color schemes, as well as any other
color scheme you can think of.
Here I finally figure out how icons work in Arch Linux (and probably
other distributions as well). Other changes include a smaller font size,
more gaps, and less line size.