Note that we enable lxdm before revoking privileges. The user can
start lxdm manually after this script is finished, but ideally the
system should first be rebooted to ensure that any kernel updates
are applied properly.
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.
Note that plasma-integration is used for KDE theme support without
installing the entire plasma-desktop. The breeze_cursors theme is
included in the breeze package, and xorg-xsetroot is used to change
the default X shaped cursor to a pointer.
Since I figured out how to run both KDE and GTK applications with
their proper settings under any lightweight window manager, and since
I now know how to configure these programs independent of their desktop
environments, this commit removes plasma-desktop, with the possibility
of gnome-shell bring removed in a future commit as well.
The rationale is that using a desktop environment is counter-intuitive
when you already use a window manager. Having multiple desktop environments
to start a session with is certainly amusing, but not at all practical,
especially when you can accomplish anything that needs to be done with
any window manager.
Switching between GNOME, Plasma, and bspwm also caused some inconsistent
X settings that I assume are non-trivial to fix without a proper restart
of the X server.
Simply starting the Plasma desktop environment will create quite a few
files in ~/.config. These files consist of window coordinates and other
non-friendly things, which, IMO, should not belong in the *user's* config
directory.
Regarding other software, GNOME MPV is arguably easier to use and less
buggy than baka-mplayer. Manipulating archives is also much easier with
file-roller than it is with ark. Since I got Audacity to look decent on a
HiDPI display, I no longer have a use for Kwave, which did not have some
of the essential features I used in Audacity anyway.
l3afpad functions much more like a notepad than kwrite, which is what
I'm looking for since I already use Vim. Using Cantata as a mpd client
is simply not the same as using ncmpcpp. zathura and evince are more
than enough for document viewing, hence the removal of Okular.
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.
