Since urxvt and termite now look very similar to each other (except for
transparency), and since images do not play nicely in tmux / transparent
windows, it makes sense to separate tasks between the two.
Sometimes you may want to use an editor that is Not Vim. Although such
an editor may be feasible for the majority of users, an editor that is
Not Vim will not behave exactly like Vim, even with plugins.
Existing Vim users should not try to use Code as an editor. It is
instead a useful editor for when someone needs to use a Non Vim editor
on your machine (although you certainly should *not* condone this).
Code does, however, feature a useful file explorer that requires no
configuration nor maintenance to use. It just works.
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.
I used to not know much about shell scripting, but now that I do,
polybar-specific bspc commands can be handled through the launch.sh
shell script instead of directly from bspwmrc.
This lets us launch different bar styles with different bspc options, or
even set styles for no bar at all.
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.
I don't think I've ever used these keybinds after I learned about
holding the left mouse button to move windows and holding the right
mouse button to resize them.
If you don't have access to a mouse, you probably don't need to resize
windows anyway, and certainly not float them. tmux is still an option,
and the preselect ratio option of bspc is still there.
Ultimately, since sxhkd just runs shell commands, you can resize windows
through a terminal or shell script as well.
This commit also removes the "switch to previous node" keybind, since
an option like that changes often and may behave unexpectedly if
another node is focused with the cursor.
I tried to do this before, but couldn't figure it out. Now that I
understand more about how windows in X11 work, and now that I know more
about shell scripting, writing this functionality became trivial to do.
There is a shorthand syntax offered by sxhkd that helps us make our
config files more compact. I avoided this syntax at first since I was
new to the software, but now that I've used bspc, sxhkd, and the shell
enough, the shorthand syntax is more concise and easier to read.
I once tried to simplify bspwm terminology back when I started using the
WM. Although it helped me use bspwm in the short term, there were some
things I was still confused about (for example, I did not know the
difference between a node with the fullscreen state and desktop with the
monocle layout).
This commit fixes that.
There is no need to check for whether or not a certain mode is set,
since bspc has a feature that automatically uses the previous mode if
the same mode was detected.
Also, "monocle" is a desktop layout, not a node mode. And modes are
states, not modes. I confused the terminology quite a bit when I was
starting out with bspwm (maybe to make the transition easier?) but now
that I've used it long enough, I feel comfortable using the proper
terminology. All future bspwm-related commits should (hopefully) contain
the proper wording.
I don't know why I couldn't implement it before, but now that I know
more about shell scripting, I know that this works. There's an even
better solution I found in the bspc man pages, which will be covered
in the next commit.
This sets the cursor to breeze_cursors by default in our window manager.
Now we have a universal theme cursor for both the window manager and
GTK / KDE applications.
wal.vim includes a color scheme for lightline, but it only plays nicely
with neovim. This commit conditionally loads the wal color scheme since
using it in vim will throw multiple errors.
The solution I used previously for padding in termite did not change the
padding color when other software such as pywal changed the color scheme.
This fixes that, so now it is possible to change color schemes
fully in termite without having to spawn a new terminal. This is
very nice, and also works well with termite's transparency feature.
Instead of manually changing every instance where a program could run to
use the config in the cache directory, and instead of copying files
every time pywal is updated, it makes sense to create symbolic links for
these files instead.
This ensures that the right settings are used even without knowing the
passed parameters.
Since tmux is such a useful program, and since we don't need to worry
about images in termite, it makes sense to start all termite windows
with tmux. This lets us use any and all termite sessions in urxvt as
needed.
Before pkill would try to terminate the script since it had "dunst" in
its name. This is the solution for that, and it also makes adding new
commands in the future easier.
Termite works exceptionally well as a transparent terminal, so I'll just
let termite focus on true color, transparency, and displaying emoji
while urxvt focuses on universal theme changing and images in the
terminal.
There doesn't seem to be a terminal out there (yet) that handles both of
these things in all the software I want, so this compromise is good
enough.
With these settings, the cursor looks exceptionally well even with
HiDPI. Adapta is used over other GTK themes since Adapta has very good
padding defaults. Adapta also won't cause problems with input fields,
compared to several other GTK themes.
After comparing environment variables between KDE Plasma and bspwm, I
finally figured out that QT_SCREEN_SCALE_FACTORS was needed as well for
full HiDPI support. With this setting and QT_FONT_DPI applied, KDE / Qt
applications now look exactly as they would in Plasma.
To avoid any differences that may arise, I also exported XDG_DATA_DIRS
and some other variables set by Plasma.
This is the last commit I will make regarding Plasma with bspwm
support. This script is required to start Plasma with bspwm, although
it is much better to run KDE applications from bspwm instead.
This commit makes the post-wal script a bit more aware of its
environment. This is only to support Plasma with bspwm, which
needs the bspwm settings but not the dunst settings.
Since bspwm with KDE settings performs exceptionally well, I may drop
Plasma with bspwm support altogether and revert this commit at a later
date. The overhead of wmctrl and grep may not be worth it.
Additionally, the filename should probably be changed to a more
generic one in order to support more software as needed.
Since Plasma does not respect feh, it makes no sense to set a
background for it.
Note that these settings apply to Plasma with bspwm, *not* bspwm with
KDE settings. You should not have to use Plasma with bspwm, since bspwm
with KDE settings should do everything you want and much more.
In the future, I may remove Plasma with bspwm support altogether.
Since wal is used to manage the color scheme, it needs to be started
when running KDE Plasma. This script does just that.
Note that the desktop background is not changed (-n) since Plasma uses
its own background manager and does not respect feh.
Instead of starting urxvtd with urxvtcd, start it automatically with
systemd. This lets us run urxvtc directly in other desktop environments
without having to rely on urxvtcd.
Although I use stow to manage my dotfiles, the way you need to invoke
stow is different depending on where the dotfiles directory is located.
To circumvent this, I wrote a Makefile that automatically determines
the stow directory (the parent directory) and package directory (this
repo) before calling stow.
Previously I separated my .vimrc into multiple files in attempt to
organize it. Now that I know more about vim, however, using only one
config file leads to less moving parts. Additionally, I now use less
vim settings altogether since I frequently have to work on foreign
machines, which probably won't have my .vimrc anyway.
