Support sourcing configuration files after plugins have been loaded

[ginzberg]

Description

The problem: Keybindings are loaded before plugins have fully been loaded, resulting in many erroneous "invalid dispatcher" errors on initial load. This can safely be ignored by the user, but it could also have a 'boy that cried wolf' effect where actually important warnings or errors are ignored by sheer habit.

Proposal: Allow for an exec-after and/or source-after feature. At the most basic level, this could be delayed until after all plugins have been loaded. At the more complex level, it could be per-plugin specific, and only execute upon success and provide warning on failure.

Real world example: I use a plugin that provides per-monitor workspace list (hyprsplit), which brings a more dwm-like experience to Hyprland. In order to use this plugin, one needs to revise their keybindings and use the plugin-provided equivalents for workspace, movetoworkspace, and movetoworkspacesilent (split:workspace, split:movetoworkspace, and split:movetoworkspacesilent).

In an ideal world, I would maintain keybindings for the Hyprland inbuilt commands, hyprpm would load the plugin, and then upon successful loading of the plugin, a new set of keybindings would replace the default dispatch keybinds with the plugin-specific equivalents.

This would fail gracefully (fallback on default behavior if for any reason the plugin fails), and reduce erroneous errors.

I suspect that this is not an uncommon issue with other plugins, but these have been my experiences.

[yawor]

I think current approach with hyprpm is broken and adding variants of source keyboard to load different things at different stages is just trying to work around the issue.

IMHO it would be better if hyprpm provided its own plugin (hyprpm.so) in addition to the hyprpm executable. Then, instead of using exec-once = hyprpm reload -n you could just load it as a plugin at the beginning of the config: plugin = /usr/lib/hyprpm.so (the path is just an example, it would depend on the distribution and/or hyprland install method).

That way the hyprpm would start much sooner and would be able to load all the plugins before loading the rest of the config file. I think it'd be quite clean and pretty solution to the problem and it doesn't require any changes to the hyprland itself.

Another approach would be to just delay displaying the debug message until after running all the execs. But I think it's uglier solution.

[yawor]

@zakk4223 I've read your answer to #4709. What do you think about the approach I've described?

[zakk4223]

The problem with a 'hyprpm plugin' is that plugin = is also deferred until the config is parsed. You'll still get the error flash, but I guess it'll go away faster if that plugin is able to load the plugins faster than the current approach does.

Another possibility would be tighter integration with hyprpm: like Hyprland asks hyprpm what plugins to load, loads them and THEN starts parsing the config. That's probably too fragile and a potential nightmare if a plugin starts crashing the compositor on load or otherwise behaves terribly.

Now that errors are retrievable via hyprctl configerrors, those of us with a bunch of plugin dispatcher bindings might just be better off with debug:suppress_errors and writing a small widget for our bar that yells at us if there are actual config errors...

Maybe a way to create config sections as 'don't actually parse this section unless plugin X is loaded'?

[yawor]

The problem with a 'hyprpm plugin' is that plugin = is also deferred until the config is parsed. You'll still get the error flash, but I guess it'll go away faster if that plugin is able to load the plugins faster than the current approach does.

Ah, Ok. I've based my idea on the experience I get when I put plugin = /some/path/to/hy3.so. If I do that instead of starting hyprpm, I don't see any errors on hyprland start, even for a fraction of a second.

Another possibility would be tighter integration with hyprpm: like Hyprland asks hyprpm what plugins to load, loads them and THEN starts parsing the config. That's probably too fragile and a potential nightmare if a plugin starts crashing the compositor on load or otherwise behaves terribly.

In that case there would definitely need to be some failsafe mode which would allow to start hyprland without loading any plugins.

Now that errors are retrievable via hyprctl configerrors, those of us with a bunch of plugin dispatcher bindings might just be better off with debug:suppress_errors and writing a small widget for our bar that yells at us if there are actual config errors...

I see it's not yet in the released version, but this looks promising :).

Maybe a way to create config sections as 'don't actually parse this section unless plugin X is loaded'?

Hyprland config file already has a plugin section, where you put a plugin specific config. Maybe it would be enough to extend that section to also allow binds inside plugin's config and merge them with bindings in the global config only when this specific plugin is loaded? Maybe also it could allow source keyword. This way it would do what @ginzberg asked for.