mirror of
https://git.allpurposem.at/mat/WiggleWobble.git
synced 2025-12-23 13:01:28 +01:00
Update README, update Makefile
This commit is contained in:
parent
27fe82f602
commit
70e05e5068
1
Makefile
1
Makefile
@ -26,6 +26,7 @@ OBJECT_DIR=obj
|
|||||||
|
|
||||||
# Compiler flags
|
# Compiler flags
|
||||||
COMPILE_FLAGS=-g -fPIC --no-gnu-unique -std=c++23
|
COMPILE_FLAGS=-g -fPIC --no-gnu-unique -std=c++23
|
||||||
|
COMPILE_FLAGS+=-fdiagnostics-color=always
|
||||||
COMPILE_FLAGS+=-I "/usr/include/pixman-1"
|
COMPILE_FLAGS+=-I "/usr/include/pixman-1"
|
||||||
COMPILE_FLAGS+=-I "/usr/include/libdrm"
|
COMPILE_FLAGS+=-I "/usr/include/libdrm"
|
||||||
COMPILE_FLAGS+=-I "${HYPRLAND_HEADERS}"
|
COMPILE_FLAGS+=-I "${HYPRLAND_HEADERS}"
|
||||||
|
|||||||
28
README.md
28
README.md
@ -21,6 +21,8 @@ at the top of the repository file view.
|
|||||||
For a code editor, I recommend VS Code or Neovim, but anything that can use Clangd will work
|
For a code editor, I recommend VS Code or Neovim, but anything that can use Clangd will work
|
||||||
If you use Clangd, `make clangd` will generate a simple `compile_flags.txt` file with the proper
|
If you use Clangd, `make clangd` will generate a simple `compile_flags.txt` file with the proper
|
||||||
include paths and flags, which will make Clangd recognize the includes etc.
|
include paths and flags, which will make Clangd recognize the includes etc.
|
||||||
|
Alternatively, use [bear](https://github.com/rizsotto/Bear) to generate `compile_commands.json`
|
||||||
|
which is a bit more granular.
|
||||||
|
|
||||||
> **Warning**: Compiling the plugin should still be done using GCC 12+. Clang does not properly
|
> **Warning**: Compiling the plugin should still be done using GCC 12+. Clang does not properly
|
||||||
> build Hyprland, and is very fussy about the hook system. You will most likely encounter errors
|
> build Hyprland, and is very fussy about the hook system. You will most likely encounter errors
|
||||||
@ -35,24 +37,23 @@ that.
|
|||||||
|
|
||||||
When building your own plugins for testing, you will need to manually define it using
|
When building your own plugins for testing, you will need to manually define it using
|
||||||
`export HYPRLAND_HEADERS=(PATH_TO_HYPRLAND_SOURCE_ROOT)` before running `make` commands. You
|
`export HYPRLAND_HEADERS=(PATH_TO_HYPRLAND_SOURCE_ROOT)` before running `make` commands. You
|
||||||
can use a local path if you keep `Hyprland` source anyway, but I'd definitely recomment using
|
can use a local path if you keep `Hyprland` source anyway, but I'd definitely recommend using
|
||||||
`hyprload`. If you use your local source different from the `hyprload` one, make sure to
|
`hyprload`. If you use your local source different from the `hyprload` one, make sure to
|
||||||
run `make pluginenv` in the Hyprland folder.
|
run `make pluginenv` in the Hyprland folder.
|
||||||
|
|
||||||
And here, excuse me, but I will go on a tangent about why `hyprload` is great:
|
|
||||||
|
|
||||||
#### Hyprload, and why it's useful for plugin development
|
#### Hyprload, and why it's useful for plugin development
|
||||||
If you use `hyprload`, it will keep a copy of Hyprland source code up to date with the Hyprland
|
If you use `hyprload`, handing `HYPRLOAD_HEADERS` becomes a bit easier and more reliable.
|
||||||
version you're running in `$HOME/.local/share/hyprload/hyprland`, and you can use that as your
|
By design it keeps a copy of Hyprland source code up to date with the Hyprland version you're
|
||||||
|
running in `$HOME/.local/share/hyprload/hyprland`, and you can use that as your
|
||||||
`HYPRLAND_HEADERS` path.
|
`HYPRLAND_HEADERS` path.
|
||||||
|
|
||||||
When installing your plugin on other people's computers, `hyprload` will automatically define
|
When users install your plugin via `hyprload`, it will automatically define `HYPRLAND_HEADERS`
|
||||||
`HYPRLAND_HEADERS` to that path to ensure maximum compatibility.
|
to that path to ensure maximum compatibility.
|
||||||
|
|
||||||
When developing plugins and frequently changing them, the `make install` command will
|
When developing plugins and frequently changing them, the `make install` command will
|
||||||
automatically place your plugin build in the directory `hyprload` automatically loads. You can
|
automatically place your plugin build in the directory `hyprload` automatically loads. You can
|
||||||
reload plugins when testing using the `hyprload,reload` dispatcher (bind it in your
|
reload plugins when testing using the `hyprload reload` dispatcher (bind it in your
|
||||||
`hyprland.conf`
|
`hyprland.conf`, or execute via `hyprctl dispatch hyprload reload`)
|
||||||
|
|
||||||
#### Making it Your Own
|
#### Making it Your Own
|
||||||
To change your plugin name, version, and author (that's you!) there are 3 variables that need
|
To change your plugin name, version, and author (that's you!) there are 3 variables that need
|
||||||
@ -70,16 +71,21 @@ After making sure you have defined `HYPRLAND_HEADERS` (you might need to do this
|
|||||||
you open a new terminal* if you don't put it in your `.bashrc` or `.zshrc` or whatever), the
|
you open a new terminal* if you don't put it in your `.bashrc` or `.zshrc` or whatever), the
|
||||||
steps to build are simple
|
steps to build are simple
|
||||||
|
|
||||||
### Manual way of doing things
|
### Manually
|
||||||
- `make`: This will build the `PLUGIN_NAME.so` file.
|
- `make`: This will build the `PLUGIN_NAME.so` file.
|
||||||
- `hyprctl plugin unload $PWD/PLUGIN_NAME.so`: If you have an old version loaded, unload it
|
- `hyprctl plugin unload $PWD/PLUGIN_NAME.so`: If you have an old version loaded, unload it
|
||||||
- `hyprctl plugin load $PWD/PLUGIN_NAME.so`: Load the plugin
|
- `hyprctl plugin load $PWD/PLUGIN_NAME.so`: Load the plugin
|
||||||
|
|
||||||
### The `hyprload` way
|
Do note that if you only load/unload from the same path, Hyprland can ignore your changes.
|
||||||
|
|
||||||
|
### Using `hyprload`
|
||||||
This works rather well in nested Hyprland sessions, since `hyprload` keeps sessions separate.
|
This works rather well in nested Hyprland sessions, since `hyprload` keeps sessions separate.
|
||||||
- `make install`: This will build and copy the plugin to the `hyprload` plugin directory.
|
- `make install`: This will build and copy the plugin to the `hyprload` plugin directory.
|
||||||
- Reload `hyprload` for the changes to take effect
|
- Reload `hyprload` for the changes to take effect
|
||||||
|
|
||||||
|
This doesn't have the issue of ignoring changes, because of how `hyprload` handles its loaded
|
||||||
|
plugins.
|
||||||
|
|
||||||
### Nested Hyprland
|
### Nested Hyprland
|
||||||
Developing a plugin may be tough. You might crash Hyprland a couple times. For this reason,
|
Developing a plugin may be tough. You might crash Hyprland a couple times. For this reason,
|
||||||
it's a good idea to develop them in a nested Hyprland session. If you run `Hyprland` from an
|
it's a good idea to develop them in a nested Hyprland session. If you run `Hyprland` from an
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user