This fixes an issue where podman was causing NixOS virtual machines
(which depend on QEMU) to not start with the following error:
qemu-kvm: could not stat pidfile /run/user/1000/pulse/pid: No such file or directory
This was my attempt at replacing vim-nix-rummik with treesitter. Note
that there was actually a case where inline yaml wasn't highlighted at
all, so I'll probably stick to the tried and true vim-nix-rummik, even
if it has the parentheses bug with lua.
This works, however some of the syntax highlighting with treesitter
feels worse compared to the default syntax highlighting, so it may be
more useful to keep it disabled.
This was my attempt at using Podman on NixOS. Although it worked and was
cool, Podman actually breaks audio for QEMU VMs and results in an error
message that returns 0 hits on search engines.
Fixes network connectivity in the virtual machine. Necessary due to the
change to the Mullvad packaging that required resolvconf to be disabled
on the host.
This setting causes some videos to experience lagginess on my iGPU. In
the future it may be useful to enable the new profile "high-quality" if
I have a dedicated GPU.
Note that in addition to setting the profile to high-quality, it's also
possible to use "vo=gpu-next".
See: 703f158880
Fixes an issue where the newer version of wine would cause my current
wine prefixes to crash with missing DLL errors. Might be fixable by
creating new prefixes with the new version, however it's much easier
for me to stick with what's known to work.
See: https://github.com/NixOS/nixpkgs/pull/273232
I tried this for a few days and although the auto-semicolons were cool,
they'd sometimes get in the way. I haven't used the keybind much at all
however, so I may remove this in the future.
Kernel version is now 6.1.67 to avoid the ext4 data corruption bug.
Additionally, typst-lsp had to be removed since it fails to build. No
solution has been posted in the GitHub issue yet.
I used Emmet years ago but at some point preferred Pug in Vue. Now that
I use React more, this should make creating tags in JSX easier.
The emmet language server is particularly useful since it becomes
possible to tab complete HTML tags.
I was going to wait until the next nixos-unstable release, but it's been
a week since the branch was updated. This commit makes it possible to
use the latest nixos-unstable release without worrying about the
fzf_key_bindings error introduced in the recent fzf update.
Since my changes are now upstreamed, I no longer need to use a personal
nixos-unstable branch. This makes it easier to use the source code of
the repository and simplifies the updating process.
Makes it possible to use sakaya without worrying about the container
automatically restarting on config changes and closing all the wine
applications.
This was previously part of my personal nixpkgs branch but I turned it
into an option that should hopefully be upstreamed soon.
This one is a lot simpler without all the merge commits in the history.
I should be able to eventually upstream the changes I made to
nixos-containers once I understand how to make those changes
configuration options.
This makes it possible to do things with the bar such as toggle it
without killing it, however I like the advantages that restarting
ironbar completely give.
Although I originally wanted to make some cool pull requests for stylix,
it turns out that adding such features would be non-trivial due to the
lack of home-manager support. Since I implemented the functionality I
wanted in my own config already, there's no need to maintain a separate
stylix branch.
Although maintaining my own home-manager repository was a nice learning
exercise, I don't contribute to home-manager enough to warrant having a
personal branch.
Since my pqiv pull request was merged upstream, my branch is basically
the same as upstream anyway.
This makes it possible to create multiple containers without duplicating
code. This may be useful for having an internet container and a no
internet container.
2 months ago, I figured out how to make Crystal work on NixOS and made
an upstream PR to fix Crystal being unable to find -lpcre. Unfortunately,
that change hasn't been merged yet and I even encountered a core dumped
error when trying to build Crystal myself recently.
Although people may be busy, I am concerned about the popularity of
Crystal relative to other languages. It could be the case that the build
was broken for so long precisely because no one used Crystal, and that
the language isn't popular enough to generate comments on the patch either.
In any case, JavaScript/TypeScript is here to stay, and it certainly has
better tooling and community support than Crystal at the moment. Deno
has been going strong for a few years now, and now that I know Rust, I
can also contribute to it if I want to.
Similar to the previous commit, I'm trying to reduce build times here.
Containers are great but each one increases the build time by a
non-trivial amount. By limiting the amount of containers and using
virtual machines for things that "absolutely need to be virtualized",
build times overall should be more productive.
I'll rename this later, but basically I got tired of the vastly
increased build times due to having multiple containers, and would
rather combine containers where possible.
Although unfortunate, this should still be better than not using
containers at all, and by making the usage of such containers easier,
the probability of using them increases as well.
This also has the advantage of fixing an issue where
hyprland-relative-workspace would prevent new workspaces from being
created in the previous direction when a special workspace was present.
exa hasn't been updated in a few years and has noticeable bugs such as
columns not working when the terminal is large enough that multiple
columns can show.
This combined with su makes it possible to automatically start a user
environment with sakaya-server running, thus eliminating the need to
spawn a shell with machinectl.
The white flash when starting hyprland is a deal breaker for me
personally and I'd rather not have to deal with it. Should hopefully be
fixed in a later release since it seems to be a wlroots issue.
Although this was cute, there are simply too many bugs and other
inconveniences to be worth it. For example, the bar cannot be focused
when a workspace has a fullscreen application.
This is kinda cool however v0.27.2 and above appear to introduce a white
flash for me when starting Hyprland. Because of this, I'll probably stay
on v0.27.0 for the time being and only patch things I really want.
This was my test of the hyprbars fork. It turns out that the original
version is more useful, although both versions crash whenever reloading
the plugin after unloading it once.
By including an image changer in a separate exec-once, swww works as
intended. This enables virtual machines to have a random background on
startup without the abnormally long wait time previously.
This was the only way I could get plugins to work reliably. Might look
into this in the future, but v0.27.2 also includes some changes not
present in v0.27.0.
As a reminder, the neovim module includes a bunch of additional stuff
used for development. Although convenient, another approach may be
considered in the future.
This works, which is pretty cool. One unfortunate consequence is that
networking with the host is required, thus an alternative approach needs
to be considered if one still wants to eliminate internet access from
certain wine applications.
Although this was cool, it created some inconveniences that I'd rather
not have to deal with. For example, opening a document required manually
copying the file to the container mount first.
Instead of containerizing a subset of GUI applications, it's likely much
easier and more effective to spin up a virtual machine of the current
system. That way all GUI applications benefit from virtualization and
not simply containerization, which caused issues when certain programs
detected that they were already open from the wayland socket.
A final benefit of this change is that which container an application is
running in is no longer ambiguous. Although it was possible to use
custom GTK themes depending on which container an application belonged
to, containers for system-installed applications tend to bring a large
amount of overhead. Only using containers for applications that deal
with untrusted inputs and have a large attack surface seems better in
this case.
This is unfortunately necessary to fix an issue where the external
monitor wouldn't update its state every few seconds. Not sure what the
issue is since this only occurs in applications when typing and not when
playing back video, for example.
Might change this later. The main advantage of favorites is that it
becomes trivial to launch various systemd-nspawn containers, although
admittedly the same feat can be achieved through creating .desktop-like
files for thunar.
Makes things simple and avoids having multiple ways to do the same
thing (launch applications).
Note that two dots are used here since at some point I presumably made
a wrapper inside a wrapper, which should probably be fixed later.
Fixes an issue where auto-indents would be automatically removed with
the auto-save plugin enabled. Should probably fix this behavior later
so auto-indent works properly with all files.
This lets me do things like only update inputs when I want to.
Additionally, it becomes easy for me to add my own functionality to
these projects and contribute to them upstream. Finally, it becomes
easier to verify changes to the system when pulling changes from
upstream.
This makes it possible to define specializations that are technically
modules without having them placed in the modules directory. This is
mainly useful to separate core Hyprland logic from desktop environment
logic.
Although rofi was cute, ironbar may suit my needs better since I don't
actually need a launcher that shows all desktop files. This makes things
simpler and makes the launcher (ironbar) easier to extend upon since
it's written in Rust.
Unfortunately, there are too many issues with favorite applications at
this time to warrant the usage of them. On the bright side, only showing
open applications makes it easy to determine all applications that are
open at a glance.
Instead of remembering which workspace an application is in, it's easier
to simply go to the previous or next workspace until reaching the desired
application.
This has the advantage of less keybinds used and no longer having to reach
across the keyboard when dealing with 6 or more workspaces.
Workspace state can be handled by ironbar's launcher instead, which has
the additional benefit of guaranteeing that you see all open applications.
hyprland-relative-workspace is used here for a GNOME-like workspace
experience. Hyprland's built-in m+1/m-1 would cycle the workspaces
instead of opening an empty one, and the recently merged r+1/r-1 does
not skip empty workspaces in-between other workspaces.
This was a test of using dots for workspaces, although ultimately
workspace indicators may be removed entirely in favor of an overview
feature in the future.
Fixes an issue where the new "full" option would cause letters such as
"m" to appear disoriented.
For more information, refer to the commit below:
b5d2d701d1
After using Logseq for a few months, using Obsidian for just a little
bit is quite repulsive. Taking notes that aren't in outliner form feels
alien and not worth it for me personally.
This makes it possible to change the wallpaper with a button press.
Unfortunately, waybar does not support hover indicators for custom
modules, so there's no way to tell that this button is clickable.
The taskbar is more useful than the window option, takes up less space,
and shows the title of any window on hover without having to worry about
vertical alignment.
This was mainly useful on smaller screens where window contents took up
less space overall, however this makes it non-trivial to determine
whether or not gaps are enabled unless two or more windows exist in the
same workspace.
Since the gaps aren't an issue with larger screen sizes anyway, slightly
reducing gaps and disabling no_gaps_when_only seems like the play here.
This was my attempt at migrating from diff-so-fancy to delta. Although
having an easy-to-hack-on rust code base was certainly appealing, there
are some minor inconveniences such as longer diffs by default.
For simplicity, waycorner will not be used as an option to execute
commands. This should prevent any unexpected surprises and we no longer
have to deal with waycorner getting hidden by other windows.
This fixes an issue where fullscreen windows would previously cause swww
and other background image setters to not show backgrounds until a
gesture animation was completed.
pqiv is an image viewer that, unlike feh, has native support for
Wayland, which makes working with it quite nice. It also supports
showing a thumbnail mode that lets you preview and switch between
images with ease, as well as the ability to run custom commands
based on the current image.
pqiv has more features than imv *and* anti-aliasing *actually works*,
making it an ideal choice for image viewing on Wayland. After years of
using feh, I am quite happy that I found pqiv.
Now that waybar supports fullscreen indicators, I am no longer
interested in maintaining a list of application names. Although this was
cool, it doesn't scale and adds complexity.
This was my attempt at using waycorner with waybar, however it fails
since waybar shows above waycorner. This commit is purely for historical
purposes.
Note that specializations increase the build time and therefore
shouldn't be used unless you're actually using those specializations.
For example, a normal Hyprland build of 30 seconds becomes 1 minute and
30 seconds with the GNOME and Plasma specializations enabled.
As an alternative, you can use multiple nixosConfigurations and only
build GNOME and/or Plsama on demand, then run those desktop environments
as virtual machines inside of Hyprland, which lets you use both (or even
all three) at the same time.
Having some indicator that we're in a container is better than no
indicator at all. starship takes forever to compile, so patching it
would introduce excessively long build times.
The previous commit didn't actually work, and I shouldn't need to
change the variables often, so it's much simpler to not have them.
In the event that I do need to change something, rg and sd should get
the job done well.
This configuration is specifically intended for x86_64-linux and likely
wouldn't work on aarch64-linux. Additionally, the configuration name may
be different than the hostname if desired.
It seems like all wine windows may be broken, although there doesn't
seem to be an easy way to allow the resizing of all wine windows without
affecting other windows. In practice this *shouldn't* matter much,
however.
wineWowPackages.stagingFull has better compatibility than waylandFull
and runs more applications without black screens. The difference between
stagingFull and wine-ge is that wine-ge doesn't crash when encountering
an error like ELFCLASS64 and usually opens windows larger and
fullscreen-like.
The reason stagingFull is preferred over wine-ge in this case is that
stagingFull is a part of nixpkgs and doesn't suffer from a black screen
bug when a hidden menu pushes the content in the window viewport down.
Additionally, although wine-ge avoids crashes in more cases, this
results in applications running that may or may not fully work, and
sometimes results in black screens where there should be graphics
instead.
This was a different wine version that let me achieve better
compatibility with Unity3D programs. Although it doesn't crash when
encountering a ELFCLASS64 error, for example, it does have other issues
like a black screen flash when opening a hidden menu (the kind that
become available with the alt key on a keyboard).
Now that I have figured out how to get all the Windows applications I
previously used working under Wine (including those that didn't work in
the virtual machine after trying to manually install dependencies) there
is no reason for me to use vmware.
Using NixOS for Windows applications allows them to be used with
systemd-nspawn containers, thus achieving things like isolation, private
networks, impermanence, and more. All of this without having to maintain
a separate operating system install.
No ports need to be forwarded right now, however this is a good example
for when ports need to be forwarded from a container to the host in the
future.
Now I don't have to wait for anything to be included in nixos-unstable
and can simply merge whatever I want whenever I want. This also has the
advantage of not having to specify which input is needed to get a
package from.
Now that I am able to understand and read NixOS/nixpkgs source code, I
understand that the usage of the npm module isn't needed since I don't
configure npm at a global level.
Networks are a way to start multiple NixOS virtual machines at the same
time. Although cute, networks seem to be used more for "test scripts"
and ultimately don't support Nix flakes. This results in package
versions being outdated and the inability to use our existing
home-manager input and other flakes.
Multiple nixosConfigurations, on the other hand, enable us to setup
entire computers that don't *have* to be virtual machines, but can be
virtual machines if we want them to be. Additionally, it becomes trivial
to only run the configurations you want to run, without having to worry
about everything being tied to everything else. Finally, persistence is
optional and the resulting .qcow2 file is quite small.
Ultimately, Nix flakes are a more flexible solution to the older
nixos-build-vms command, and should be preferred over it in pretty much
all cases. To reiterate, if you're using flakes, there's no reason to
use the outdated nixos-build-vms command, which won't have the same
package versions as the ones in your flake.
This *works*, and it's possible to edit files in one virtual machine
while having those files instantly be updated in all other virtual
machines. Note that the host will also have access to the files, which
ultimately means that directory sharing is quite useful (and convenient).
This was a change to make networks somewhat usable, and it works to a
good extent, however I ultimately decided against using networks due to
their missing flake support.
This is a working example of using the modules in our existing
configuration to start a network of virtual machines with
nixos-build-vms. Note that VMs take longer to start up in this case than
nixos-rebuild build-vm, and that said VMs may lack certain functionality
(such as dynamic resolution in GNOME) that would otherwise be present
with build-vm.
Although networks are certainly cute (and I'm glad that I feel familiar
with them thanks to my better understanding of Nix), they do seem less
convenient than nixos-rebuild build-vm and don't appear to support Nix
flakes. Networks therefore seem more useful for running multiple one-off
services that couldn't otherwise be ran in a container.
Mainly a proof of concept. Eventually I'll devise an easy way to view
notes in a pretty way and edit them with neovim (likely through your
typical web framework tools).
This fixes an issue where some applications were using the default fonts
from nixpkgs instead of the fonts specified in the system configuration.
Notably, this led to the use of "TeX Gyre Heros" for body text, which
made distinguishing between i/I/l problematic at smaller font sizes.
This *works*, and the best part is I didn't have to do *anything* (besides
write this configuration file, that is).
Thanks to NixOS, it is possible to have GNOME, Plasma, Hyprland, and
whatever else you want installed on the same computer without those
desktop environments conflicting with each other. This configuration is
done in a fully reproducible and declarative setup with minimal code,
without having to modify any external files or run any imperative
commands.
This makes it possible to boot into either Hyprland (the default) or
GNOME. Having separate configurations implemented in combination with
home-manager and impermanence guarantees that desktop environments don't
conflict withe each other, so this could also be used to implement a
Plasma specialization in the future.
Although many people have tried to make more modern top-like programs,
my favorite is still htop *by far*. NixOS includes htop-vim in its
official repositories, which is great, and this change removes the
/nix/store prefixes from all the processes, making htop overall much
easier to read and navigate.
Possibly useful for setting up computers with GNOME. The main advantage
GNOME has is the ability to have a consistent environment in both X11
and Wayland, which is useful to test whether or not something only works
in X11.
Unfortunately, some files may require the use of document editing
software like libreoffice. Fortunately, systemd-nspawn containers enable
us to ensure that these documents do not have access to the internet.
Previously I decided against using srb2 in a container due to the poor
performance I experienced. Since I figured out how to use the graphics
from the host inside of the container, performance is no longer an
issue.
Even though it's possible to guarantee that a certain package is used,
it's still necessary to include packages in the $PATH in order to have
access to the man pages for them, among other things.
This results in a consistent environment when using any given shell.
Note that adding a package to $PATH instead of just referencing it where
it's needed is useful since otherwise the man pages are inaccessible.
This fixes some neovim plugins throwing errors due to missing things
such as language servers.
Note that although it *would* be possible to abstract this functionality
into a variety of imports, options, or other abstractions, including
everything at once should reduce complexity since I am not interested in
maintaining different states of configuration. In other words, either
everything works, or something doesn't work and then everything works.
Note that this container uses home-manager from the Nix flake on the
host system, which is pretty cool.
Currently modules in this repository *don't* differentiate between
home-manager and nixos, but this could be changed in the future to
support e.g. my home-manager neovim config on a non-nixos system.
This plugin enables smooth integration between fcitx5 and neovim. In
order words, you no longer have to manually change input methods when
switching between normal mode and insert mode.
This lets us take advantage of nix strings while having the entire
config in a single portable file.
Note that someone already wrote a home manager module for joshuto, which
should get merged soon.
See: https://github.com/nix-community/home-manager/pull/4004
This fixes an issue where Hyprland would drop from 60fps to 45fps after
being idle for some time, often 1 minute and 30 seconds. This was
problematic for viewing content while idle at 60fps with XWayland in
windowed fullscreen.
See: https://github.com/hyprwm/Hyprland/issues/2484
The current crystal binary in nixpkgs complains about not finding pcre
when you try to compile anything with it, so crystal-flake is necessary
to have a working crystal environment under NixOS.
crystal-flake additionally packages crystalline, which is nice since no
one has been able to successfully create a pull request for nixpkgs yet.
Reference: https://github.com/NixOS/nixpkgs/issues/129002
Note that the theme file is necessary to avoid the theme changing in
certain situations. The keymap config is the same as the default, except
with the addition of "o", which is used to select files (or a directory)
when using joshuto as a file chooser.
When blur is enabled, it should look like things are actually blurred.
This has the advantage of making translucent windows work better when
the opacity is set by hyprland.
After waiting 41 minutes to produce an output iso of 6.9 GB, the iso
itself failed to boot when trying to start it. Rather than dealing with
this excruciatingly long build process, I'd much rather use nixos-rebuild
build-vm.
This actually causes QuitPre to not close neovim since the tree is
closed first when quitting while the tree is focused. For simplicity,
the tree should always be unfocused to avoid ambiguity.
Unfortunately (or fortunately), every line matters when reading and
writing software. Because of this, increasing the cell height results in
more negative consequences than positive.
This overall makes it easier to keep track of options we might want to
change (and might be defined in multiple places) without having to worry
about where those places actually are.
Although I could just integrate this directly in configuration.nix since
everything is a module, having a separate hardware-configuration.nix
makes it easier to integrate with other devices that may output
different configurations.
Since all of these files do roughly the same thing (that is, configure
the system in a specific way that a separate file seems necessary), this
should reduce the overall complexity of the project tree.
This is my attempt at putting all modules in one directory to avoid
having to remember whether a module was a part of applications/,
desktop/, or terminal/.
This fixes an issue where containers caused the boot process to slow
down, especially those that relied on mounting directories only
available once a graphical session has already started.
Since I never use previous generations, booting the newest entry by
default seems ideal. In the case that something is broken, it should be
possible to return to the menu by pressing space at boot.
This commit fixes the cursor being upside down and inaccurate in
Hyprland. Note that show-cursor=off is used to avoid the duplicate
cursor issue described in https://github.com/swaywm/sway/issues/6581
Unlike GNOME, Hyprland does not automatically change resolution on
window change, so fullscreen is enabled by default to ensure a certain
size. In the future, a script could be used to adjust the resolution as
needed.
Related: https://github.com/hyprwm/Hyprland/issues/1056
I originally used GNOME for virtualization because the cursor in
Hyprland was upside down and its position was offset by a noticeable
amount. However, now that I've figured out how to make Hyprland work
under QEMU with an accurate cursor, this is no longer needed.
Although this was useful at some point to make GNOME usable, a virtual
GNOME instance works quite fine without this script.
Whether I even need GNOME virtualization is debatable due to how much I
was able to achieve with containers. Benefits of containers include not
having to start up a virtual machine, easy sharing of files with the
host, and having the window manager manage all windows.
I figured out how to get wine working on Nix, and it works surprisingly
well, however I'd like to avoid programs from writing wherever they want
and don't want to rely on a solution like firejail.
As it turns out, systemd-nspawn containers enable us to run wine applications
in a reasonably private container without access to neither the files of the
host nor its internet connection.
This should make things easier to change and maintain over time, with
the ultimate goal of making it easy to provide example configurations
that can be expanded upon.
This was my working solution at forwarding ports from a container to the
host. Although mullvad no longer supports port forwarding, this example
can still be used to forward e.g. web services from containers to the
host.
Unfortunately, libvirt / QEMU / KVM / virt-manager etc. aren't quite
there yet when it comes to virtualization of non-Linux guests. Since I
do not have the equipment necessary to pass through a second GPU, it's
much easier to rely on the current dominance that VMware has in the
field.
Note that with the latest version of waybar with the experimental flag
enabled and the latest version of hyprland, patching waybar *shouldn't*
be necessary.
The center orientation is broken when using a vertical waybar.
Additionally, using only two orientations for horizontal and vertical
workflows guarantees that ratio modifiers behave as expected. This works
since most applications have a focus point near the top left of the
window.
Joshuto is *significantly* faster than ranger and is written in Rust
instead of Python. Although both ranger and joshuto have not seen a new
release in a while, the future of joshuto seems more promising.
Joshuto is additionally faster than lf and, similar to lf, does not hang
when previewing images with kitty.
This was more annoying than not due to having to re-establish an
internet connection every time the lid was closed. Other advantages
include the possibility to use the computer while closed.
I would love to commit to hyprland and not use any other Wayland
compositor (at least until something better comes up). For this reason,
this commit assumes that X-specific settings are exclusive to hyprland.
barbar-nvim was a non-trivial plugin that changed buffers to tabs.
Although this was cute, I like neovim's default buffers since they
*don't* show up as tabs.
Borders aren't that useful when you already know which window is being
focused. In the event that you need to know which window has focus, you
can either look at waybar or use a toggle that dims inactive windows.
"activeworkspace" can be useful if you aren't interested in the special
workspace, but since it ignores special workspaces, it causes this
script to behave unexpectedly.
swww has some advantages like webp support (something that was rejected
for swaybg due to the feature not existing in a library they were
using). Additionally, it's convenient to only have to worry about one
swww instance instead of multiple swaybg instances.
This works well since I am not interested in different users on the same
machine having different state, and keeps all the relevant configuration
for specific programs in one file.
This fixes an issue where floating windows would have their focus lost
if you accidentally moved the mouse while on the window behind it.
This also fixes an issue where focus would be lost on a special
workspace if the workspace in the background had a fullscreen xwayland
application.
I'm really not interested in maintaining chromium since it doesn't come
with sane defaults like ublock origin. Since qutebrowser uses chromium,
it should work fine as a chromium replacement if needed.
This fixes an issue where certain fullscreen xwayland applications would
break when attempting to switch to the same workspace.
Note that `bind = SUPER, grave, workspace, previous` may have also
solved this issue, however it's currently broken on master.
Because of how easy it is to create and run virtual machines in NixOS,
the use of containers is not necessary. Virtual machines additionally
outperform containers when it comes to graphical tasks, and allow for
the usage of a variety of GUI applications separate from the host.
In order to avoid conflicts with keybinds in the GNOME VM, removing
per-key orientation switching and replacing it with one key that
switches between all orientations seems ideal.
Vertical is nice since the animation is faster and covers less of the
screen. It works well with the master layout since you can easily see
the master window of each workspace.
Being able to have unique partitioning schemes for each workspace (as
long as they're using the master layout) is a nice advantage of Hyprland
over other compositors like river.
Note that this uses the base0A, base09, and base02 colors specifically.
The first two are the accent colors used by Stylix, and the last one is
the color that was closest to Hyprland's default.
Unfortunately, telescope-nvim was a downgrade from fzf-vim due to lack
of transparency out of the box, a different window size, and searches
not showing by default.
Although I'm sure it's *possible* to use the colors from Stylix in my
custom theme with Nix, it may take some time for me to figure out how.
Pull requests welcome.
This fixes an issue where the cursor would occasionally show in
fullscreen applications where the cursor was not expected to show.
The cursor will still disappear when using kitty.
I personally find it frightening that I was previously using PKGBUILDs
in Arch Linux for something that could have been so elegantly achieved
with Nix and NixOS.
Unfortunately, the system occasionally gets stuck at the dreaded "stop
job" message at times. I haven't delved into figuring out the cause yet,
but this change ensures that shutdowns occur in a timely manner.
Unfortunately, KMSCON was extremely buggy and caused a variety of
graphical glitches and random character sequences across a non-trivial
amount of virtual consoles. Because of this, Hyprland as the main
environment will be preferred with a way to emulate a tty-like
appearance.
Although it would be nice to use a Wayland image viewer, currently all
of them (that I am aware of) suffer from anti-aliasing issues not present
in feh.
Note that instead of searching for the background at runtime, it is
likely possible to reference the background at build time when the
hyprland config is migrated to Nix.
After using Nix and NixOS for a few days, I can't believe I did
something like this in the past. Having a single reproducible flake is
significantly more pragmatic than imperatively configuring everything.
A wallpaper is required for Stylix to work, so I added one with base00
as the background color and the NixOS logo as the foreground image.
Credit for the logo goes to the original author who licensed it under
CC-BY: https://releases.nixos.org/nix-dev/2016-October/021876.html
Alacritty does not support MapleMono-NF as a font, whereas kitty does.
kitty also has other nice features such as built-in windows/tabs and
image support.
Note that loading a runtime file in ~/.cache/wal is no longer necessary
since configuration is done declaratively through Nix.
Although this has some downsides, such as the lack of "live reloading"
in some applications, this "feature" wasn't present across all
applications anyway.
Stylix is like a maintained version of pywal but configuration changes
are managed by Nix and Home Manager, thus guaranteeing a certain level
of reproducibility with its declarative nature.
colorizer bugged out presumably due to order being determined by the Nix
language. I did not like cursorline however I did think cursorword was
cool, so I'm keeping that part of it for now.
Although I could technically make a gnome module and make it really easy
to switch between gnome and hyprland, I'm not really interested in
maintaining that right now.
For example, there was a recent bug in nautilus where deleted files
would not show up as deleted. There was another bug where opening a
terminal would not focus the terminal window. I'd much rather use
hyprland in this case due to the faster release cycle and simpler code
base overall.
For anyone that wants to contribute, you are free to do so. Now that my
configuration is simpler, however, as well as with the experience I've
gained over the years, there should be less things that need changing.
This was cute, however I didn't actually use the changelog. Now that I
am using NixOS with Hyprland, the old changelog is irrelevant, and any
changes I make should be easily discoverable since things are simpler
now.
- code: No plans to use anything that isn't neovim.
- picom: Don't need anymore thanks to Hyprland.
- polybar: X11-only. yambar/waybar work as alternatives.
- tint2: X11-only. Functionality can be replicated with waybar.
- xinit: No need when using Wayland.
Similar to fish, there's some relief in knowing that I can declare my
starship settings in Nix and have them accessible from any user on the
machine, even root.
I originally wasn't going to mix logic from my dotfiles with NixOS,
however I was unable to simply use my abbreviations after adding
~/.config/fish/config.fish, so I decided to give it a try.
Using Nix to manage fish abbreviations feels nicer than using a
config.fish because I am now easily able to manipulate these
abbreviations with the limitless possibilities of the Nix language, and
with the guarantee that the output is reproducible.
Highlights:
- Added a test container with network configuration and Wayland support
- Added GNOME/Hyprland support with SDDM
- Added Git/Starship/GPG support
- Properly added Neovim support with .enable
- Various package changes
- Made caps lock function as escape on tap, left ctrl on hold
- Print screen functions as right super on hold
I used bspwm for over half a decade, and although it was great, I am now
interested in using Hyprland, which is basically bspwm for Wayland but
better.
These are my first steps towards using Nix and NixOS to declaratively
configure a reasonably good development environment. I am aware that
there are various paradigms that include using home manager and/or
flakes, however I am still exploring with a simple configuration.nix.
Notable changes:
- Set a background, start yambar, set volume, and play audio on startup
- Remove gaps by default
- Remove blur
- Increase special scale factor
- Show red for xwayland windows
This is an alternative to the default swapmaster behavior that, instead
of swapping with the first child, swaps with the last active window if
the currently focused window is master.
river is a cool Wayland compositor that I've been trying for a few days
now. There are some bugs and unimplemented features, however, that make
me want to use Hyprland instead.
Many of these settings are not necessary to change since they're the
default anyway, and by using the defaults, important settings should be
automatically applied over time.
Changes include:
- fcitx5 support
- Removed middle click paste
- udiskie starts by default
- Internal screen is 1x scale by default
- Acceleration profile is flat
- swww settings added
- Gaps are smaller by default
- No border by default
- Master layout by default
- No rounding by default
- Special workspace uses fade animation
- New windows become master
- rofi used over of wofi
- Super+O to toggle waybar
- Super+U to toggle between master/dwindle layouts
- Super+S to toggle special workspace
- Super+Ctrl+[0-9] for river/dwm-like tag behavior
- Super+Alt for group keybinds
- Volume/brightness keybinds
I never use this and it was actually making tab not work when at the end
of of a word. Getting rid of it entirely means less running code that I
have to maintain.
Pressing the actual number of the desktop is more productive than
tabbing between them since you associate the hand movement with that
workspace, making it easier to return to later.
Super+tab, in contrast, was one hand movement that resulted in many
different results, which wasn't so good for memorizing which desktop has
what.
I don't think I've ever had to change from SUPER in my years of using
Linux, and if I ever had to, it'd be a simple find and replace.
Using SUPER explicitly here makes things easier to read and understand
without having to worry about additional variables.
Super+Enter is now the infamous new terminal keybind, and Super+Q now
closes windows as expected.
Other changes include using a single instance for kitty and adding
basic screenshotting functionality.
This is huge and means that I no longer have to use the buggy libinput
hacks that I used previously. So far, I haven't experienced any bugs
with hyprland gestures that I experienced with libinput-gestures.
From my initial testing, hyprland seems quite nice and opens new windows
similar to bspwm. Not having to specify whether a window should open
horizontally or vertically makes things feel a lot smoother compared to
sway.
This change, in combination with xdg-desktop-portal-termfilechooser-git,
was my attempt to use ranger as a file browser. Although it worked, it
unfortunately caused ranger to crash in some instances, likely due to
incorrect parameters.
I initially programmed this "dynamic desktops" implementation for a
similar feel to GNOME, however after using it for a few months I
realized that I was taking away one of the main advantages of a tiling
window manager by having all windows not tile by default.
Additionally, I ran into some edge cases where the next window would not
show if opened on a desktop that had multiple nodes open. Although I
could probably figure out the cause with some effort, I'd much rather
enjoy the simplicity of the traditional tiling hierarchy once more.
This gives us the convenience of switching desktops while also giving us
the option of the traditional alt+tab approach if needed.
Note that all desktop-related keybinds use the super key so alt and ctrl
modifiers can be used by desktop programs.
This fixes an issue where, at some point, I changed the behavior of
Super+Tab to switch desktops. Having both options gives the flexibility
of choosing whether or not you want to see the other windows while
tabbing through them.
Not sure if I'll remove these again. All I know is that I'll no longer
have to worry about not having certain dotfiles if I want to try a
particular setup again, which is nice.
Although removing these dotfiles gave the repository a clean feeling, it
made it significantly harder to resume using a certain window manager or
other tool at any time.
Instead of removing dotfiles entirely, it's enough to simply not install
the programs you don't want to use, or even install them but not open
them.
2 months ago, I removed bspwm in favor of GNOME. After using GNOME as a
daily driver for some months now, I can appreciate it as a nice desktop
environment for many GNU/Linux users, however it does not meet my needs
as well as a customized window manager setup can.
In reality, I don't need *too much* from a window manager; it just needs
to manage windows in a reasonable way. For anything else I need, I am
free to program it myself as a learning exercise. I prefer understanding
most if not everything running in my environment versus having various
GNOME utilities running in the background.
After using firefox for a while, a deal-breaker for me was that the
regular version is impossible load custom extensions for without signing
them before-hand.
Although it's possible to load extensions through about:debugging every
time the web browser is started, it's significantly easier for me to
simply use librewolf and not worry about it. Additionally, I can now
leverage the many additional features librewolf has compared to firefox,
and now no longer have to worry about "configuring firefox" after
installing it.
Now that I use GNOME, I no longer have a need for neofetch since GNOME
has its own about page in the settings. This also means I no longer have
to deal with neofetch being unmaintained and fetching the wrong
background images under GNOME.
feh was one of the fastest image viewers I've ever used, however since I
now use GNOME, having a minimal keyboard-only image viewer is no longer
necessary.
Although zathura is a great piece of software that opens pdf files at
blazing fast speeds, I no longer have a use for it since GNOME's
document viewer works just as well, and even lets you use a mouse with
it!
The recent blur additions in picom were absolutely stunning, and I'm a
bit saddened to have to leave it, however I also no longer need to worry
about the compositor only working under X11.
tint2 is a great piece of software that I enjoyed playing with, however
it is drastically easier and more convenient to simply use dash-to-panel
in GNOME if you're looking for that traditional taskbar-like experience.
As a bonus, such a taskbar would work under both Xorg and Wayland, have
features such as preview on hover, and won't have anti-features such as
the bar not being clickable unless you perform Xorg shenanigans.
After over 5 years of bspwm, I have decided to enjoy myself in the
luxurious life that is GNOME.
Using bspwm and window managers in general was an invaluable learning
experience that gave me a deep understanding of many of the novelties
of the current linux desktop computing model. It had a profound impact
on my understanding of how operating systems work in general, and I
now wish to move on and enjoy modern GNOME simplicity.
What a ride. Although I absolutely loved configuring my keybinds through
sxhkd, more so than i3 / sway and similar window managers, I didn't
realize that most of what I was doing under bspwm could also be
accomplished under GNOME through gsettings.
Since I now use GNOME, I no longer need to worry about configuring a
separate program to show notifications. Although GNOME notifications
aren't nearly as customizable, they match the theme of the desktop
environment and get the job done.
Although qutebrowser was very cute, there are too many disadvantages to
using it that can be solved by simply using a more mainstream browser. I
cover some of those issues in previous commit messages.
Note that although this was great from a proof-of-concept point of view,
it's significantly easier and more effective to simply use the yomichan
add-on in a web browser like firefox.
This was the configuration I used for tint2 when I was trying to
replicate a taskbar-like experience in bspwm. Although it worked to some
extent, the dash-to-panel extension for GNOME handles this much nicer,
and with the many other benefits GNOME provides.
dual-function-keys is an amazing piece of software that solves many if
not all of the long-lasting issues I had with binding caps lock to ctrl
and escape. I have additionally configured it in a way such that print
screen can double as a right super key, due to it being next to right
alt and right ctrl on the T14.
This was my configuration for librewolf, a web browser I used for a few
months before ultimately deciding to use firefox again for simplicity.
Although librewolf is useful for giving individuals immediate access to
a solid browser with ublock origin pre-installed, the downsides such as
not having automatic updates for users that need it the most, as well as
constantly depending on another project to update in a timely manner,
do not seem worth it in the long-term.
This was my configuration for qutebrowser, a web browser that I
revisited in 2022 and decided to use for a few months. Although I
certainly found the experience quite cute, I came across issues such
as the content window blanking when switching workspaces, strict https
mode not being supported, containerization requiring separate tabs, and
frequent crashes when dealing with large amounts of tabs.
Besides the issues above, I also had to deal with certain websites
not loading in qutebrowser without any way to troubleshoot it from
developer tools. In addition to the lack of extension support (thereby
requiring more involved measures to replicate similar behavior found in
other browsers) and the inferior content blocking solution, I ultimately
decided to switch back to my old trusty friend firefox.
This was my implementation of dynamic desktops, largely inspired by the
various hints I found on r/bspwm. Although this was a very engaging
intellectual exercise, I eventually realized that GNOME handles dynamic
desktops much better, and comes with a slew of other conveniences as
well.
Realistically won't be using custom backgrounds with kitty due to the
complexity involved in changing them among other things. Setting the
background opacity and letting the desktop environment manage the
background instead is more convenient.
Having image diffs in the terminal is very cool, however I ultimately
decided against using kitty's diff feature due to using the existing
colors of the shell being non-trivial.
This makes it easier to see the most relevant results first without
having to scroll up, assuming there are enough results where scrolling
up was necessary.
This added a toggleable bar similar to polybar, except this time it
showed the open applications at the bottom. I eventually switched to
GNOME, which is able to achieve this and much more with dash-to-panel,
an extension that has been steadily improving over the years.
Since I use GNOME now, dunst isn't needed, although I feel like the
dunst notifications looked cooler than the GNOME ones since they also
followed the color scheme of the environment.
I never used this key and I don't think I ever will. feh is a great
image viewer that's simple, fast, and anti-aliases things properly,
although I believe there's a high probability that another image viewer
is out there that nails all the boxes and then some.
I personally found this to be a stunning blur that I would love to use
in GNOME, however I am okay with using GNOME without it due to the many
benefits GNOME provides.
Although it was cute that I was the only one that knew how to use my
computer, standard keybinds is a pretty neat thing to have. This was
another change I programmed before deciding to use GNOME instead.
Although I am glad I eventually found a fix for this, it's much easier
to simply use GNOME with extensions and not have to worry about hacks
like these. If by chance such GNOME extensions are as hacky as the
solution in this commit, I'd argue that the convenience of those hacks
being abstracted away from the user outweighs fixing things manually.
Instead of restricting myself to 4 desktops, I eventually decided on a
setup where desktops would be dynamically created as applications were
opened. I then realized what I was doing was replicating the GNOME
desktop environment in a much less efficient way, and eventually
switched from bspwm to GNOME.
At some point I added libinput-gestures to my setup to replicate the
touchpad gestures I loved so much on GNOME. Although this was cute, such
gestures lacked the animations from GNOME and would even stop working
entirely from time to time. It is for this reason that I created a keybind
specifically to reload libinput-gestures.
For history's sake, I'm including how I changed the color scheme of
tint2 with wal. Note that I don't use tint2 anymore since I realized
that what I was trying to do with tint2 can already be achieved much
easier and much more polished with GNOME extensions.
These are old changes I made while I was still using bspwm. Although
bspwm is an amazing window manager, I feel like the simplicity of GNOME,
as well as how customizable it can be, negates any potential benefits
one can achieve with bspwm and its vast configuration possibilities.
As one example, alttab is a cool piece of software that brings the
concept of alt-tabbing to window managers like bspwm, however, GNOME is
already capable of doing this and does so in a more elegant way, showing
views of the windows you're alt-tabbing between.
Although this was cute and allowed us to open links in any browser from
anywhere on the computer, in practice this "ability" wasn't that useful.
In the event that looking up words is needed, it's easier to open or
switch to qutebrowser and use its search feature instead of trying to
remember which keybinding is which.
One solution for the future would be to synchronize qutebrowser search
engines with a rofi/dmenu-like selection screen, which would solve the
problem of not remembering which keybind is which. Frequently used
search engines would be higher on the list and would require less or no
typing beyond <CR> after the initial prompt.
Since we often use non-monocle layouts without borders or gaps, having a
separate borderless/gapless monocle mode was often confusing since we
didn't know which layout we were in. When using a status indicator with
bars like polybar, knowing the current layout required a separate script
and was overall hacky, with its state not being updated until certain
bspc events occurred.
Browsers were always a pain point for me due to the manual intervention
they often required to get extensions configured properly across
separate user profiles. qutebrowser has improved significantly since the
last time I tried it (around 2017) and supports modern browsing due to
its usage of Chromium 102 with QtWebEngine 6.4.0.
rofi was cute, however I no longer have a desire to run an external
interface for simply starting programs. This can be achieved in many
different ways through a shell, and without the disadvantages (such as
having all items listed by default) that rofi came with.
This was cute, however knowing which desktop we're on may be irrelevant
in a future workspace implementation. Adding this information to the
fish prompt with starship may also be an option.
This makes rofi work nicely with multi-monitor setups, however I was
planning to remove rofi since I can do everything that rofi can do with
a simple shell, and without having to worry about its inconveniences,
such as unreadable default wal color themes.
alttab <https://github.com/sagb/alttab> is a cool alternative to the
more traditional ways of managing windows in bspwm that lets us focus on
the currently open windows instead of which desktop they're on.
Note that I originally used this as a test to see how useful it would
be, however I quickly realized that having unpredictable desktop states
is not ideal, especially when not using a status bar like polybar.
The code was shared as a solution to a post on r/bspwm. Credits to the
original author, however I plan to ditch this solution for more
predictable desktop management.
It turns out polybar was bloat and I don't actually need one, at least
that's my current thought process. In particular the advantage of
fullscreen windows without having to worry about whether polybar is
visible or not should outweigh when I temporarily show the bar with a
keybind.
Note that while I was exploring taking advantage of bspwm's monocle
layout more, I went through a point where borders would only be visible
when multiple windows were present, which required me to use the single
monocle config variable and implement the solution proposed in the
GitHub issue below:
https://github.com/polybar/polybar/issues/1880#issuecomment-674518936
I used thunar for a while and it was a great experience with few
exceptions, however I will likely remove it in favor of a more command
line-based experience. Using thunar was a valuable learning exercise and
it helped me understand more about what file browsers actually do, and I
realized that I can replicate this experience fairly trivially while
giving me the benefits of my existing configuration.
This makes it easier to manage mpv windows like all other windows, which
lets us take advantage of watching 16:9 videos with mpv tiled while
working on other things.
Neovim has some nice additions like honoring the blinking cursor from
kitty when in insert mode. I don't remember why I used vim instead of
neovim here, but neovim is mature enough that it should be an excellent
choice to use for many years to come.
I originally made this change to take advantage of wpgtk, and although I
was successful and wpgtk was a cool experience, I am not that interested
in updating all my config files to use wpgtk instead of wal.
Since this was mainly useful for thunar and nautilus, and since I'm
considering using ranger only and writing my own scripts for additional
functionality, I may change this to a simpler theme in the future.
This makes polybar less obtrusive, however I've been considering
removing it in the long-term to maximize screen estate. Although polybar
is cute, I don't *need* to know everything in the bar every second I use
the computer. Having specialized commands or keybinds that show certain
information seems more useful in this case.
Some information, such as the date and time, could become a part of the
wallpaper itself, making blank desktops more useful than they are now.
Although widgets are also an option, I have not verified how well these
work under my current setup yet.
This makes dealing with certain Japanese files significantly easier
since we no longer have to worry about manually performing a Shift JIS
to UTF-8 conversion before opening the file in vim, nor do we have to
worry about manually changing the encoding with :e ++enc=sjis.
This makes dealing with CJK files inside vim a much more pleasant
experience. Note that automatically handling Shift JIS encoded files is
something I haven't implemented yet, although a simple keybind could
make things more manageable.
This was an experiment to see if I could make switching between desktops
easier. Instead of thinking about desktops in terms of their contents or
numbers, we can think about them in terms of gestures used to reveal
them.
The main advantage to this setup is that you can access any of the other
desktops with one keystroke. This is in contrast to having to press
super+tab twice. The other advantage is that the desktops are always at
a predictable location. One swipe to the right will always get you the
desktop on the right, whereas two super+tabs can land on any desktop.
This appears to fix an issue where the screen would occasionally flicker
after resuming from dpms' screen blanking feature. So far I have not
observed any significant performance degradations.
Reference: https://github.com/yshui/picom/issues/578
A verbosity level of 2 was cool during testing, but now that the
Makefile has been stable for years at this point, having all that
verbosity seems unnecessary. This change still shows when things are
stowed, but with less detail than before.
As far as I can tell, dual-function-keys also works in a tty, so
keystrings is no longer necessary, and you don't have to worry about
making sure that loadkeys is ran either.
These are obsolete technologies that are no longer needed thanks to
dual-function-keys, which I'll add in a future commit. This also fixes
an issue where left control would behave like an escape key when tapped,
which caused a lot of accidental escapes.
Now it's possible to use the terminal in peace, and with the volume set
to a cool amount, without worrying about audio bells when scrolling
through man pages.
I am personally not amused by some of the defaults that firefox ships
with and would rather not have to deal with them on new configurations.
Although it's possible to sync settings across devices or simply copy
the profile directory, the advantages of librewolf outweigh the cons for
my individual use case, at least for now.
I personally love this setup for language learning and it emphasizes how
far one can go with customizing their setup when using a window manager
like bspwm + sxhkd. Although it's possible to achieve the same effect in
other desktop environments, sxhkdrc makes adding new keybinds extremely
simple and easy to maintain.
This used to be a separate script in my ~/.local/bin, however the script
is short enough that it doesn't need to be a separate file, and I don't
use it outside of the shell anyway.
This is version 0.4.9 and should work out of the box without any
modifications. Note that the mpv config must be edited to support
this script, which I'll add in the next commit.
In the future it may be nice to automatically add a selection of
backgrounds that can be rotated through, or support getting those
images from an external source.
Currently this script works by getting the total play time of the
playlist when pressing F12. Time will tell if I decide to improve upon
it later, although it already does a good job at what it's supposed to
do.
Although alacritty is an amazing terminal emulator, I am not interested
in maintaining configuration files for it at this time.
The current config works and is an excellent replica of the current
kitty config. If you have a desire to use alacritty, you can use the
files in this commit to get amazing support for things like pywal.
The reason alacritty is being removed is because it doesn't fully
support fcitx. Currently "inline input" doesn't work in Xorg, and it's
impossible to see input under GNOME Wayland.
For simplicity, only the terminal emulator that works the best for me
will be officially supported, since I've never had a reason to use
alacritty anyway.
Source: https://github.com/alacritty/alacritty/issues/1613
This likely fixes an issue I had earlier, although I don't remember what
it was. In any case, this change is a positive one since toggling the
bar is now instantaneous as well.
Although recoloring documents is great for rice screenshots, most of the
time we want to see a pdf in its original form before deciding to
recolor it. Most of the time recolors occur when a "dark mode" is
necessary, which zathura does a good job with.
Previously ale would show an error message when dealing with JavaScript
files without an .eslintrc. That has now been fixed and standardjs works
as intended.
This is no longer needed since I plan to focus fully on bspwm instead.
Note that I may still use GNOME on multi-monitor setups and other
devices where having the convenience of bspwm and sxhkd isn't necessary.
Since I've decided to ditch sway, I no longer have to deal with waybar
either, which is nice. Although waybar is nice-looking, there isn't much
of a difference between it and polybar in day-to-day usage, and other
factors such as ease of maintenance are far more important.
Although using a Wayland window manager was cute, Sway always felt like
a gimped version of bspwm to me. This is likely due to many of the bspwm
features I use, as well as certain X applications not working well under
Wayland (such as feh).
I am also not interested in maintaining the config for Sway, and prefer
bspwm's approach where it's configured through bspc and shell scripting.
In summary, "after all these years", Sway is still more trouble than
it's worth for me personally, and I'd rather invest that time focusing
on my existing bspwm setup, which has always been pleasant to use.
Similar to bspwm, all keybinds are now handled with super to avoid
conflicts with other applications. In the future it may be useful to
replicate the rest of the bspwm environment under sway.
I've been trying to like vscode for years, especially since it was
widely regarded as one of the best editors of all time. As cool as VS
Code is, however, I always ended up using neovim and a terminal since
it's simply easier for me to get things done that way.
Although using mpd was a cute experience, I am not interested in
maintaining mpd on my systems anymore since navidrome does the job just
as well and has more useful features.
Although using ncmpcpp was an interesting experience, I now value the
convenience of software like navidrome more than the minimalist traits
of ncmpcpp. Realistically I should never encounter a time where
listening to music within a terminal interface is mandatory, and simply
using a web interface with optional apps drastically simplifies things.
9 months later and I am no longer interested in maintaining lunarvim. My
current neovim config does everything that I need it to do and I don't
see myself using anything else anytime soon.
I am not performing tasks that require constant knowledge of the CPU and
RAM being used, and if I am, I can use a tool like htop instead, which
would avoid the distraction of the bar numbers constantly changing.
This fixes an issue where the previous keybinds would conflict with
other applications, and reinforces the idea that all system-wide
keybinds use Super.
I've used fcitx for a while but never committed my actual config for it.
Note that this config is relatively old, and I'll be updating it with a
new commit to make seeing the changes easier relatively soon.
Having gnome settings was cute, but realistically the desktop
environment should automatically choose the best settings for the target
computer. Manually change anti-aliasing goes against the idea of wanting
the stock GNOME experience.
I don't use these anymore in my main environment and am probably not
interested enough in GNOME to customize it manually anymore. As of now,
I'd rather stay in my comfortable bspwm environment since it's there
that "everything just works".
Since I no longer use KDE applications anymore, and since I no longer
set XDG_CURRENT_DESKTOP equal to KDE, this doesn't do anything
noticeable to the working environment.
Like most things in life, it's time to move on from maintaining
Fedora-specific scripts. Although I like using Fedora when given a
random machine, my setup is much easier to reproduce on Arch Linux.
For most users, they may not even need a desktop operating system like
Fedora in the first place since mobile devices are typically more
secure, easier to carry around, and can do most if not everything that a
desktop can, especially in the year 2022.
Although writing my own install scripts was a valuable learning
experience, Arch Linux now has an official archinstall utility, which
should be easier to use than having to edit a bash script.
Although learning about package management for rpm-based distributions
was a fun experience, it's not realistic to maintain long-term. In this
case, it may be easier to simply install packages on a case-by-case
basis, making use of Ansible for anything else.
Instead of setting up a development environment directly on Fedora,
which comes at the cost of having to maintain both the Fedora-specific
implementation and the Arch implementation, it should be easier to
simply use Vagrant instead.
This change has 3 main benefits:
1. We no longer have to worry about switching between the fn keys and
F1-F12 keys, and can benefit from both keybinds at the same time.
2. Keys that don't return anything under xev (such as the chat icon and
telephone icons) can now be customized.
3. We no longer have to worry about accidentally pressing the networking
key that disables the internet connection.
Note that instead of having to remember to switch between fn and non-fn
keys, especially when working with both at the same time, we can simply
map commands that would use those fn keys with super instead.
In this way, we no longer have to worry about the same keystroke performing
a different command. The current commit serves as an easy way to remember
what the existing fn keys were if needed.
This fixes an issue where kitty wasn't able to show the ui of fcitx
under wayland. By forcing x11 specifically, kitty now has reasonably
good support for fcitx under wayland.
This slightly increases the font weight of text without affecting the
font awesome icons, which is important since changing the font weight
of everything caused the firefox icon to become malformed.
This makes our setup more consistent across the two environments, useful
when switching between them. Note that sway is not a replacement for
bspwm due to how it handles fcitx input with kitty and how it has
built-in vsync.
Since selections are more likely to be temporary than full screen
screenshots, copying their contents to clipboard by default is useful,
although in the future it may be more practical to create an image and
copy to clipboard at the same time, similar to other screenshotting
tools like ShareX.
This makes it easy to switch layouts in kitty and usually get what we
want rather quickly, without having to worry about the current layout
being used.
At some point I disabled this setting, possibly because of a bug or
other issue at the time, most likely related to my use of w3m or a
similar image preview script.
Now that I take advantage of all of kitty's features in 2022, especially
since it has proper fcitx support, there shouldn't be a reason to not
enable dynamic background opacity, as it seems to work flawlessly.
I wrote a script that generated wal completions 4 years ago. Although
the patch was never merged, pywal is a great tool and I can still use
the completions personally, so I might as well add them here.
Now polybar will show on all monitors by default, and we don't have to
update the script every time those monitors change, useful when changing
between computers that use HDMI and computers that use display port, for
example.
Now we no longer have to worry about kitty having an inconsistent color
scheme when changing the color scheme of the rest of the environment,
which means that we can fully use kitty's window management and change
themes with pywal at the same time.
Since I usually have a browser and terminal emulator open most of the
time, I have placed them back as desktop 1 and 2 by default. I'm used to
the file browser being in 3, and 4 serves as media, which is important
for language immersion in particular.
The other 6 icons are numbers for individuals that know how to read
other languages.
This enables us to automatically change kitty colors when changing pywal
color schemes, which means that kitty window management, such as its tab
feature, will honor the new colors of pywal automatically, without
having to restart kitty.
Now that pipewire is more mainstream, we don't have to worry about using
alsa or pulseaudio here which, from what I remember, took more effort
to set up.
There was actually an issue where waybar was using larger padding than
usual, which was fixed by setting the gsettings in our sway config. I
liked the padding changes introduced by the other theme, however, so
this change makes it permanent.
This was cool when we had KDE-specific applications, but since I'm
prioritizing ranger and nautilus now, dolphin isn't needed. Since I'm
focusing heavily on terminal and web-based applications, there is less
need to customize KDE applications specifically.
Two other advantages to this is that I no longer have to manually update
the colors in kdeglobals, and most if not all of the environment can be
programmatically set up with minimal effort.
Now sway behaves similarly to unclutter on bspwm/xorg, and we don't have
to worry about moving the cursor out of the way since it automatically
disappears.
Since ueberzug only works in X, and since ranger previews currently
conflict with tmux due to a new python version on arch linux, ueberzug
has no real advantage besides making image previews work in alacritty,
which I ultimately decided against due to how it handles fcitx input on
Xorg.
One of the conveniences of GNOME is auto-mounting. Although manually
mounting is a good learning exercise, we can improve productivity by
auto-mounting by default.
Looking back at this, meta packages should be one of the most convenient
ways to keep track of packages. It gets the job done and should be more
than sufficient for our use case.
In particular, installing all packages guarantees that we won't "miss
something" and have to install it manually, which is more useful than
having a lower package number count.
The main disadvantage is dealing with constant updates to large packages
in a restrictive internet environment, although it's possible to
mitigate this by separating the smaller packages from the larger ones.
This is mainly to get rid of the warning when using "git status" where
git doesn't exist when the current partition isn't the same as the root
partition.
This makes it so that mpv won't take up the entire screen when executed,
assuming it's dealing with a video resolution equal to or greater than
the current display.
This makes working with bspwm a lot cooler since the cursor is now
automatically hidden when not in use, making full screen videos and
other applications a lot more immersive.
Now it's possible to type "p" for paru instead of having to type
"pacman" or "sudo pacman". This is mostly for convenience, since I think
there's still some merit to typing things out the standard way.
Note that although it's possible to make fcitx work with alacritty as
well, the current implementation doesn't show what you're typing as
you're typing it, which is inconvenient.
Because of this, I recommend using kitty in all cases if switching input
methods is important for your use case. kitty also has the advantage of
image preview support on both xorg and wayland, since ueberzug does not
have wayland support.
Note that I previously set up a working environment with ibus-mozc
which, although was cool (and better than ibus-anthy), did not offer all
the benefits that fcitx provides. Now that I figured out how to make
fcitx work on both xorg and wayland, as well as in applications like
anki, this is my preferred input method for personal systems.
The default mpv settings use traditional rendering methods in order to
support older hardware. Since we're running on modern hardware, we can
take advantage of the higher quality settings that mpv offers.
This is similar to bspwm, except new workspaces aren't automatically
created and empty workspaces are skipped.
Although creating a script to handle this should be possible, sway
doesn't offer any real benefits to me since bspwm does everything that
sway can do with the addition of input method, image preview, and other
features being better supported on xorg.
To reiterate, I like the idea behind sway, however I am more fluent with
bspwm and xorg and prefer how windows are managed in bspwm. For software
that only works on wayland, sway is a lightweight alternative to
committing to a full-featured desktop environment like GNOME.
Since the device we're using is normal DPI, we have to manually adjust
these two values. Note that the rest of the setup is mostly automated
when it comes to determining the size of things.
We actually still need compton (now picom) for screen tearing in bspwm,
so we'll add it back now. In the future it may be useful to keep
dotfiles in the repository even when I no longer use them, since the
configuration itself may still be useful.
So far my experience with LunarVim has been positive. Although there are
some gotchas and your own configuration may be better in some cases, the
defaults used are pretty nice and should enable developers to get up and
going quickly with neovim.
I like how sway handles workspaces. This change makes it so bspwm uses
numbers as the workspaces and polybar only shows workspaces that are
being used in the bar.
Although alacritty is cool, kitty is also cool and has image support,
ideal for rice screenshots.
This commit also adds $alt for the rofi command in the previous commit.
After the contest for archlinux-wallpaper, there are a lot of high
quality backgrounds that one can choose from. Instead of worrying
about choosing an appropriate background for a desktop environment,
one can simply use archlinux-wallpaper instead.
$hostname is now defined by default so we don't need to do anything
here. I assume it wasn't always like this since otherwise I wouldn't
have needed to call `hostname` in the first place.
This admittedly makes our tmux slightly boring in comparison to those
that customize it, but having a consistent layout makes it easier to
work with tmux across different environments.
"dog" was an alternative I used to cat for syntax highlighting. Now that
bat exists (which is written in rust, by the way), there is no need to
use "dog" and I highly recommend anyone interested to use bat instead.
It turns out that I don't actually *need* image output in the terminal
(besides being cool). With that aside, I can safely use alacritty
knowing that it's written in Rust and is apparently the fastest terminal
emulator in existence.
Note that I need to update the script later or simply provide a series
of instructions so everything isn't dependant on one script.
In the past it was nice to install Arch Linux with minimal if any
console intervention, but the practicality of this is questionable
since you only have to install Arch once. A more specialized script
could be useful for mass installations, although in this case I assume
one would create such a script on-the-spot.
For those of you reading this: If possible, you should invest in neo(vim)
instead of (vs)code, as I believe there is a significant difference in
productivity when it comes to not worrying about the user interface that
(vs)code provides.
I may want to use this in the future and even if I don't use it it's not
going to have a significant impact on the computer, so I might as well
keep it here just in case.
I don't actually need to get rid of my old config files if I ever want
to have easy access to them in the future. Although I intend on using
Wayland, having a nice interface for traditional X applications may not
be a bad idea (some graphically intensive programs also run better there,
apparently).
Some nice changes here, although I may stick to alacritty for now since
it seems to be faster and I can focus on using tmux instead of having
multiple ways to manage windows.
It's the end of an era and I no longer use bspwm. Although the tiling of
bspwm was admittedly cool, at the end of the day most of my time isn't
spent opening new windows so working with the i3-like sway instead works
just fine.
Having a meta package was cool and it got the job done, but it's
inconvenient to use when adding and removing a lot of packages.
One alternative I'm looking at is simply keeping track of all the
explicitly installed packages and storing that in a text file. This
makes it easy to keep track of all the installed packages without
introducing downsides, and new machines that don't need certain
packages can simply delete those lines.
As of now I am largely uninterested in customizing neofetch to look
completely different, although time will tell if I stay true to this
stance. As of now, however, showing an image is enough.
Over time compton became unmaintained and a replacement package picom
took its place. After trying out sway for a bit, I realized that it
doesn't need a separate compositor at all like bspwm does, so I might
just switch to it. Note that there is a performance penalty on sway
that I haven't figured out how to solve yet.
evince actually uses less memory than zathura and seems to be more
efficient overall, although it isn't as customizable as zathura and
not as minimal in terms of UI.
Overall, I'd rather just use zathura, which also lets me be more
consistent in my bspwm setup.
Apparently gnome-books and sushi depend on evince, the first of which
is a GUI for djvu/epub files and the second of which lets you preview files
with the spacebar in the file explorer. Ironically, I've never used this
feature until I read about it, and although it seems cool, I don't think
I have a use for it as I've been opening my files normally for years now.
Some of these settings, specifically the window-status ones, produced
error messages in more recent versions of tmux. I've gone ahead and
simplified everything to the default colors since they work pretty well
already.
These packages aren't included by default anymore so adding them here
makes sense. Note that maintaining a large meta package is actually
difficult since one error means the whole thing doesn't work.
I am looking for an alternative solution to keep things somewhat
automated while at the same time increase flexibility when it comes
to the initial setup.
I actually wrote this in 2018 but never committed it. Might as well do
that now. The extensions it installs are uBlock Origin, Vimium, and
HTTPS Everywhere.
I wanted to commit some more stuff for 2020. Better late than never,
right? The most significant change is probably in fish_prompt.fish.
I fixed an edge case where the directory in question could be the
same as the user's username.
This abbreviation is useful when you change your color scheme with
wal and plan to or have multiple kitty windows open (since kitty
itself will still be using the color scheme it initially loaded
from the config file).
Since animated desktop backgrounds are more of a hassle to maintain than
they are worth, I've gone ahead and removed xwinwrap. If you are running
bspwm and still want an animated desktop background, use:
xwinwrap -g 3840x2160 -ov -- mpv -wid WID --loop inf your.video
For reference, you can use xwinwrap with any resolution you want, not
just your screen size. mpv will also accept pretty much any animated
format out there.
Since most of the README wouldn't be relevant to most users anyway,
I've gone ahead and removed it. In the future I may consider writing
a brief guide on how to set up certain things, but for now I'm focusing
more on the dotfiles and bootstrap aspect itself instead of trying to
treat everything as a collective whole.
It turns out that using a literal dot instead of the word dotfiles has a
negative impact on the discoverability of the repository. Since the
directory name can be changed to .files when running `git clone`, this
gives us the freedom to name the repository however we please.
This *should* complete the process of adding full variable DPI support
to an X session. The X DPI is now set dynamically and changes on
resolution change, making this setup easy to deploy to both traditional
and HiDPI environments.
This caused some problems when the ~/.Xresources DPI was 192 and the
screen resolution was 96 DPI. Since I now know how to manipulate cursor
size even after X is started, manually setting Xft.dpi in ~/.Xresources
to 96 or 192 DPI is no longer needed.
Now that I figured out how to change cursor size for all applications
and not just a select few, restarting the X session to use a new cursor
size is no longer necessary.
Changing between desktop environments is no longer a feature since
it's easier and more convenient to use only one environment, although
it's still certainly possible for the determined user.
The bootstrap script was trying to call refresh-keys when the make
target was named update-keys. Since the flag is called --refresh-keys,
it makes sense to call the make target refresh-keys as well.
Now that the desktop labels cover less width and have lower padding,
it makes sense to place label-mode on the right side instead of the left.
This fixes an issue with padding I previously encountered with the old
desktop labels, and also prevents the desktop labels from being shifted
to the right when a label-mode is present.
This lets us use the Arc Dark theme in Qt / KDE applications without
having to worry about setting it through Plasma's system settings
interface.
Note that it's probably possible to change the color values to get any
look you want; one could even automate this process through pywal, and
symlink ~/.config/kdeglobals to ~/.cache/wal/kdeglobals.
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.
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.
This removes the minimize, maximize, and close buttons from GTK
applications, since we don't use them under bspwm anyway.
Note that Qt applications should already do this, no configuration
necessary.
The cursor theme size is set based on the X cursor size, which itself is
based on the X DPI.
Note that (as far as I know) there is no easy way to change the X cursor
size without restarting the X session with the new DPI.
Lots of changes here with the goal of streamlining the installation
process. The install scripts work very well now, although there are
still some final changes that I would like to make (notably the removal
of the unzip requirement and the inclusion of more options to automate
the process even further).
It turns out that the README for the xeventbind PKGBUILD actually works
very well here. On another note, I've yet to figure out how exactly I
want to document PKGBUILDs.
This is an X-specific script that changes (mostly) everything that needs
to be changed on resolution change, with the exception of X cursor size.
Note that any programs already running are not affected. For this kind
of functionality, you probably want to use Wayland instead.
Since fonts and other desktop-related packages are now handled by
tari-desktop, this is no longer necessary. Note that I also created
tari-web before I figured out HiDPI support for Qt and GTK applications.
I initially created tari-util as a package to be pre-built and installed
in the installation media. This was a while ago, and now that I know
exactly how the installation process and PKGBUILDs work, all the
previous issues I had with makepkg turned out to not be issues at all.
Here are my PKGBUILDs I use on Arch Linux. Each has a specific use case. I use PKGBUILDs to know exactly what I have on my machine, and to make it easier to sync changes across multiple Arch installations.
Of course, you don't have to use **any** of these packages for your own installation, but if you want to use my setup, you probably want to use the packages I use as well.
## Getting Started
There are some **core packages** that need to be installed before anything else, listed below:
- [tari-core](/.archlinux/PKGBUILDs/tari-core) - Core packages I use for many things
- [tari-cli](/.archlinux/PKGBUILDs/tari-cli) - CLI programs that are nice to have
- [tari-desktop](/.archlinux/PKGBUILDs/tari-desktop) - Packages I use common to all desktop environments
### Add-on packages
Now that everything is installed, it's just a matter of choosing a desktop environment or window manager. Note that you can install multiple DEs and WMs at once, then switch between them with your display manager.
- [tari-gnome](/.archlinux/PKGBUILDs/tari-gnome) - The GNOME desktop environment, with GTK-related software
- [tari-plasma](/.archlinux/PKGBUILDs/tari-plasma) - The Plasma desktop environment, with Qt and KDE-related software
- [tari-bspwm](/.archlinux/PKGBUILDs/tari-bspwm) - The bspwm window manager, with optional Qt and GTK support (through `tari-gnome` and `tari-plasma`)
Other window managers exist, but may not be trivial to use in non-traditional (HiDPI) environments.
### Other packages
- [tari-scripts](/.archlinux/PKGBUILDs/tari-scripts) - Color scripts, purely for aesthetics
- [tari-util-xeventbind](/.archlinux/PKGBUILDs/tari-util-xeventbind) - Useful to change X DPI on resolution change
[Arch Linux][archlinux], a [GNU/Linux][gnulinux] distribution, lets you build your own environment. Since you only install what you want, it is easy to customize and control.
## Features
- A universal color scheme consistent across all terminal software
- A universal theme across both Qt and GTK applications
- The ability to switch between GNOME, Plasma, and bspwm efficiently
- Full HiDPI support for Qt, GTK, and X-level software applications
- Easily switch between both traditional and HiDPI resolution in the same X environment
## Usage
On a fresh [Arch install](/.archlinux/install-scripts), run `./bootstrap.sh`.
Here are my Arch Linux install scripts. They are divided into 4 parts:
1. Pre-install: Setting up the drive to install Arch on
2. Install: Installing Arch Linux to that drive
3. Configure: Writing some basic low-level config files
4. Post-install: Post-install configuration
I have one `install.sh` script that calls the first three scripts with the proper settings. The fourth script should be ran after a reboot. (TODO: Probably easier to run a subset of post-install commands in the installation media, + internet will already be covered, which allows us to clone this repository to the newly created home directory and run any other post-install commands on first boot... may also be useful to divide the install scripts a bit further to support more options).
> **Note**: If you do not understand my install scripts, you should follow the [Installation guide][archguide] instead.
This is my setup for [Fedora][fedora], a [GNU/Linux][gnulinux] distribution that ships with GNOME by default, making it an ideal choice for most users. This guide covers a *simple* rice that will make your Fedora look much nicer than the defaults. It only uses packages from the official repositories, making it quick and easy to set up on any machine.
> This guide will work with the **latest version** of Fedora (29 as of this writing).
## Use my GNOME theme and settings
To copy the look and feel of my GNOME setup, run:
```sh
make rice
```
That's it! You now have a very simple Fedora rice.
## Use my packages and scripts
### Install kitty
Use `make kitty` to install the [kitty](/kitty) terminal emulator.
### Install wal
Use `make wal` to install [pywal](/wal).
### Install crystal
Use `make crystal` to install the [Crystal][crystal] programming language.
### Install rustup
Use `make rustup` to install the Rust toolchain installer.
## Mimic my entire setup
If you want to use *everything* I use, simply run the bootstrap script, like so:
```sh
./bootstrap.sh
```
The script will ask for sudo permissions the first time you run it. Then you can sit back and relax as no manual intervention is necessary.
My [NixOS] configuration with [Nix Flakes], [Home Manager], [Stylix], and [Hyprland].
<sub>Background art: [The market](https://www.peppercarrot.com/en/viewer/artworks__2022-02-21_The-market_by-David-Revoy.html), [In Bloom](https://www.peppercarrot.com/en/viewer/artworks__2022-03-02_In-Bloom_by-David-Revoy.html) and [Vertical cover book two screen](https://www.peppercarrot.com/en/viewer/artworks__2016-11-14_vertical-cover-book-two_screen_by-David-Revoy.html) by David Revoy − [CC-BY 4.0](https://creativecommons.org/licenses/by/4.0/deed.en).</sub>
<sub>Background art: [Video game jam](https://www.peppercarrot.com/en/viewer/misc__2023-06-12_video-game-jam_by-David-Revoy.html) by David Revoy − [CC-BY 4.0](https://creativecommons.org/licenses/by/4.0/deed.en).</sub>
## Features
- Clean, readable code that can be easily modified to add/remove things as needed.
- Fully reproducible and declarative environment thanks to NixOS.
- Reasonably secure containers isolated from your personal files and network.
- Nix Flakes + Home Manager + Btrfs on LUKS.
- Simple yet effective Neovim setup with nvim-lspconfig.
- Modern Wayland support with Hyprland and the master-stack layout.
- Full Japanese support with fonts, input method, and wine covered.
- Specializations for easy switching between Hyprland, GNOME, and Plasma.
- A universal color scheme inherited by all applications.
## Usage
### Replicate my [Arch Linux](/.archlinux) setup
On a fresh [Arch Linux][archlinux] install, run the bootstrap script.
First, install stow with your package manager. Then, run the following:
```sh
make package=kitty
```
This will symlink my kitty config to your `$XDG_CONFIG_HOME`. If you want to install a different package, simply replace `kitty` with the name of the directory you wish to get dotfiles from.
Since `stow` will only change what it owns, you do not have to worry about any of your existing dotfiles being changed when you use this method.
To uninstall packages, simply use:
```sh
make uninstall package=kitty
```
This will remove the symlink to my kitty config. If you have other kitty files, stow will not remove them, since stow only changes what it owns.
#### Method 2. Manually
If you already have dotfiles and want to improve them, you can use this repository as a guide. If you find something that makes your dotfiles better, you're free to use it.
If you don't want to use stow, you can simply copy/paste the dotfiles you want to their relevant directories.
## Updating
To update your system with any changes I make, you must first verify that the changes I made are actually changes you want. Eventually I want to consider my dotfiles "stable" (i.e. 1.0.0, 2.0.0, etc.) in which only major version upgrades would significantly alter existing functionality, but right now this simply isn't the case.
Once you've verified that you indeed want my changes, update your local copy of the repository like so:
```sh
git pull
```
If you used the stow method, all of the dotfiles that you use from me will already be updated; you do not have to do anything else. If git tells you that there are conflicts, you probably want to rebase your changes on top of mine, or consider making your own version of those files instead.
## Downgrading
If for some reason you updated by accident and want existing functionality back, you can simply checkout a previous version or commit.
For example, if your configuration was last known to work at commit `a1b2c3d`, you would use:
[GTK][gtk] is the widget toolkit used by Firefox, Electron, and many (if not all) GNOME applications.
GTK's `settings.ini` only affects window managers and not the GNOME desktop environment. This is because GNOME manages user preferences with [`dconf` through `gsettings`][gnome].
## Use Cases
gtk-settings can be used to:
- Control the appearance of GTK applications under non-GNOME environments
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
