Since I'd like other people to try my dotfiles, I will be writing
READMEs for each package directory, which should hopefully cover
anything a user needs to do in order to use the package.
"Desktop" was a really generic package name that didn't describe the
contents of what it contained. Since we already have a catch-all
directory (extras), I separated "desktop" into what it actually was:
settings for urxvt/termite and settings for xmodmap.
Some other programs may also use xrdb. The only reason the term files
are not in the bspwm directory instead is because it may be useful to
use urxvt or termite in non-bspwm environments.
It is now possible to install only a specific set of dotfiles instead
of everything at once. To do this, simply run make and set the "package"
variable from the shell. For example, to only stow my vim config, use
`make package=vim`.
The desktop directory is used for desktop-related things that may be
useful outside of bspwm (such as caps lock functioning as ctrl +
escape). Whether or not this is needed is questionable, but it is an
option for now.
It may be better to further split these directories and avoid the
generic word "desktop" altogether.
Previously I wanted to stow everything at once, but now that I know how
to use Makefiles a bit more, I can still stow everything at once with
multiple directories. Additionally, this allows people (myself included)
to only stow the dotfiles they want, such as only vim or only fish.
Instead of separating *every* file into its own directory, I've opted
instead to group common configs together and only use separate
directories where they make sense (e.g. a vim config).
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.
Having a monocle-like layout on a tiled desktop layout is more
confusing than it needs to be. If single_monocle is ever needed,
it can be manually set on-demand instead.
Setting the file type of a file is different than simply changing its
syntax. In this case, the rofi config was treated as a real .java file.
By setting syntax explicitly, we avoid re-declaring the filetype.
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.
