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.
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.
If I stayed on zsh instead of switch to fish, I would've probably never
known how easy it is to add certain information to the prompt. Since
the prompt itself is just a function, you can run any commands you want
inside it to get information, including git commands.
This commit adds the current branch you're on only when inside a git
repository, and only when you're not in a tty.
Realistically, you use a window manager to take up all the available
space on a screen. Borders and gaps are counter-intuitive in this
regard.
Since polybar has a module that shows the title of the focused window,
using a border width even in gapless mode is no longer necessary. This
also works conveniently well with bspwm's monocle desktop layout, which
will also inherit the no-border no-gaps methodology and take up all the
available screen space.
It turns out that polybar is able to provide very useful information for
window management in bspwm, so much so that disabling the bar completely
wouldn't make sense.
Since there's already a way to hide the bar (with a sxhkd keybind), and
since a "no bar" option would break this functionality even though the
hidden bar keybind produces the same result, it makes sense to remove
this.
