speedwm-personal/docs/about5
speediegq 4050d66caf Update:
- Fix bug in speedwm-help caused by crazy sed usage
- Add def files in docs
- Update templates (not sure why I took so long)
- Add a few more lines to about5
2022-09-10 11:22:35 +02:00

28 lines
2.5 KiB
Plaintext

-- Switching run launcher --
Some users may prefer to use a different run launcher than dmenu.
Previously all scripts bundled would only run dmenu from $PATH but you can now switch run launcher very easily.
- Edit options.h and change RUN to your run launcher
- Add "export RUNLAUNCHER=<runlauncher>" to your .<shell>rc
Run launchers must support dmenu arguments because otherwise scripts are going to be incompatible.
It must also support the additional '-g' argument that the dmenu grid patch provides unless you modify the scripts bundled.
Keep in mind that if you use a different run launcher, it may not support Pywal/.Xresources.
-- What is up with /usr/share --
speedwm occasionally writes files to /usr/share. These files contain information about speedwm.
- The documentation you're reading when you press Ctrl+Alt+h is stored there (as separate files).
- speedwm-bindir is stored there which is a file that contains the path to the binaries on your system.
- speedwm-compositor is stored there which is a file that contains the defined compositor.
- speedwm-layouts is stored there which is a file that contains all available layouts.
These files are pretty important so it is recommended that you do not delete them.
If you do end up deleting them though, you can just make clean install on speedwm again.
-- Maintaining settings easily --
speedwm is a personal fork of dwm and will therefore likely have keybinds and other options you may not like. Because of this, I recommend that you use the patching system to manage your "custom" settings
speedwm has a patching system. It allows you to create a patch with your changes to options.h, options.mk, toggle.h and toggle.mk. To create a patch, simply make clean install once and then the docs folder will contain backups of your source code. If you perform changes to any of these four files, run make patch to create patches against the backups in docs and your modified files. Then once you're updating, do make patch_remove, git pull, make patch_install, and make clean install and all your settings will be there.
The only (obvious) problem with doing this is that eventually the backup files patches are being created against will be pretty old causing patches to no longer apply correctly. If this is the case you will need to create new patches and backups.
If this seems like more effort than it is worth, maintaining your own fork is always an option. This allows you to perform any options you want yourself. This however doesn't allow you to grab any updates so this should be your second choice.