It turns out that manual intervention is necessary to resolve dependency
conflicts (bspwm-round-corners-git replaces bspwm), so it is easier to
simply install bspwm-round-corners-git later if wanted.
It turns out that yay automatically handles the process of installing
package dependencies not in the official repositories. This is very
important for some PKGBUILDs, so I've gone ahead and let yay handle
all the AUR packages I build.
This is the PKGBUILD I made for a [nice patch][1] that adds border
radius support to bspwm. The patch has not been merged upstream yet,
so this PKGBUILD will have to do in the meantime.
[1]: https://github.com/baskerville/bspwm/pull/856
Since anyone using Tari will probably want the web browsers too,
this change makes sense.
Since all of Tari is now in one PKGBUILD, it is easy to see everything
that will be installed, and it becomes trivial to add or remove packages
as needed.
Updating firefox extensions manually is not ideal. Additionally,
this method is non-trivial to apply if the target system does not
use pacman as the package manager.
Since Tari will work as an independent PKGBUILD now, and since
xeventbind is an individual program not related to Tari, it makes
sense to remove the associated prefix.
Since I don't have to worry about the completeness of individual desktop
environments, this makes it easier for me to tailor the tools I use to
my use cases.
With the default shadow settings, gapless windows would have a shadow
extending far into the polybar above.
This change makes gapless windows show a light separator shadow that
distinguishes the window from the bar. It also fixes a problem with
the appearance of the dock shadow in less noisy environments, while
maintaining the shadow look for floating and tiled windows at the
same time.
Since the collective system is known as Tari, having individual parts
for the pieces that work together to make the whole is not ideal.
Now that I understand more about how Arch Linux works, if I ever needed
to create a non-Tari operating system, I would just use pacman to install
packages as needed, or modify this PKGBUILD to create a new meta package
specific to that system.
color0 is usually the background color, but not always. This fixes an
issue where polybar would not display the right background color if
color0 was different than the background color set by the pywal theme.
This should make web interfaces and editorconfig-equipped text
editors show the correct amount of spacing for tab characters.
This should also make it easy for contributors to use the right
indentation and other file settings.
Not all of these packages may be useful to everyone, and that's fine.
Any list I create won't satisfy everyone, but reducing the number of
PKGBUILDs makes it easier to see and change all the packages installed
on the system as a whole.
Due to the nature of how Arch Linux works, most users won't even need my
PKGBUILDs. With the exception of setting up X with a bare-minimum window
manager, installing and configuring most software is as simple as using
pacman to install that software and symlinking any config files you want
to their relevant directories, if any.
There is an open bug that should be resolved before or during the
Arch Linux Bug Day coming up next month (January 2019). Either way,
manually updating the httpie version becomes impractical after some
time; it's best to apply this fix upstream instead.
Since my .vimrc already installs the same version of vim plug,
and since any user can symlink my dotfiles, using a PKGBUILD to
install it is redundant and arguably less portable.
As ironic as this may sound, less user choice means that there's less
room for error. Plus, it makes things conveniently easier for me and
possibly every other user of the software.
Realistically, if I'm installing the tari packages, I more often than
not want everything with it. If I am aiming for a minimalist setup
without X11 or Wayland, I will probably not use the tari packages
anyway.
Feel free to contribute to my dotfiles. I think it's great if
anyone uses them, since I tried to make them easily approachable,
extensible, and usable.
This makes it easier to immediately start using dotfiles and other
config settings on first boot. It may even be useful to add an option
to run the entire bootstrap script in the installation media. Note that
if this route is taken, some assumptions regarding installation will
have to be changed to adjust for the chroot environment.
This commit makes it so that downloading the entire repository to run
the install scripts is no longer necessary.
It assumes that you have an active internet connection, which should be
a given since you need an internet connection to run pacstrap anyway.
Now that I use borderless and gapless windows by default, the window
management feature of kitty has become even more useful to me. This
change makes it easy to determine the active kitty window.
Despite having used tmux exclusively before, I have grown accustomed to
the benefits of using kitty as the window manager. tmux may still be
useful, for example, over ssh, but kitty is arguably the way to go for
local user sessions.
Note that this will affect the output of `env` since color codes are
used. Using a function to invoke man is not ideal since fish uses its
own function for its man pages.
It turns out that merge commit messages are used to keep track of
branch information since the commits themselves only reference other
commits and the actual branches may be deleted at a future date (even
`git clone` by default will not pull in any other branches).
Personally, I find a meaningful commit message more useful than a merge
commit message, so I'll be using that instead. Later when looking at
the commit history, "Merge branch <branch_name>" will not be useful
since the mentioned branches will have already been deleted.
Some projects rebase all changes into one commit, then push that
single commit to master. This seems like a very convenient approach
for small fixes, although if done for larger changes, each individual
commit and its respective explanation is lost.
In particular, this merge commit adds a bunch of config changes that
make polybar (and the system itself) more practical to use. Borders and
gaps are now disabled by default, and can be manually set through bspc
for your ricing needs.
It turns out that the left padding from the bspwm labels are used in
addition to the left padding from polybar, so in order for padding to be
consistent across both the left and right sections, the section with the
bspwm module needs to have its padding subtracted by the amount used by
the bspwm labels.
Time will tell whether or not I keep this, but one less color makes
it easier to seamlessly integrate the bar with different color schemes.
With this change, the interface is also arguably cleaner.
It turns out that showing the window title is very useful for actually
using the window manager, especially with no visual indicator through
window borders to determine which one is selected.
