hyprland load bind config before hyprpm load plugin?

[DreamMaoMao]

I need some help.

Some of the custom dispatch commands on my plugin load before hyprpm reload, so it starts with an error.

how to fix it??

[vaxerski]

well hyprpm reload gets launched as a command, and it doesn't reload the config, your plugins should do that, in the init func.

A workaround would be to change the exec once to:

exec-once = hyprpm reload && hyprctl reload

[DreamMaoMao]

I have done this, but the boot always appears an error message, and then the error message disappears, this boot way is too ugly

[DreamMaoMao]

I want error messages to never appear, which requires the bind configuration to load after hyprpm loads the plug-in

[DreamMaoMao]

I hope you consider this need, this kind of startup is really not very beautiful
@vaxerski

[vaxerski]

what if you add the exec-once thing I showed? Worth noting you can also disable error messages in the config.

[DreamMaoMao]

Same phenomenon, the error message appears first, and then the error message disappears

[vaxerski]

I mean, it's hard to really make it be gone, as hyprpm reload is executed as a subprocess, and then hyprland carries on.

What I'd recommend I guess is just disabling the error messages for the first few seconds and then re-enabling it

[DreamMaoMao]

Well, there doesn't seem to be a better way

[dskvr]

@vaxerski What about this?

[DreamMaoMao]

what if you add the exec-once thing I showed? Worth noting you can also disable error messages in the config.

I think it's a little rude to just disable the error messag

[ArneshRC]

exec-once = hyprpm reload -n && hyprctl keyword source ~/.config/hypr/binds.conf

This works for me.

Edit: Nevermind, it doesn't.

[dskvr]

I know this topic is closed, but from both a UX perspective and a maintainer's perspective the suggested workarounds are subpar. I couldn't find any evidence of proposed solutions to this issue, either.

I have thought about this quite a bit and took a stab at solving this race condition. IMO it is a very elegant solution in a minimal changeset. It is not a complete solution, rather a proof of concept, but I believe is a start to a complete solution. However, as was true previously with other topics, I may overlooked something.

IMO The reason this doesn't sit right with me (and others) is error fatigue and the externalization of internal logic on to users, as well as the need for plugin developers to communicate these race-conditions to a group a users with varying skill and knowledge levels; which adds friction to development.

Truncated PR Description

Requirements:

1. Low maintenance
2. No breaking changes
3. No regressions to existing configurations or plugins.
4. 30 minute timebox

UX and development issues resolved:

1. errors == errors == true.; Users are only shown actual errors, not side-effects of internal race conditions
2. Eliminate the externalization of internal logic on to users; user's shouldn't need to remember if they have errors turned on or off.

I have successfully tested and validated the following cases:

1. Valid dispatcher for valid plugin; successfully defers and the error is dismissed without displaying
2. Invalid dispatcher for valid plugin; successfully defers and is thrown once plugin is loaded
3. Dispatcher for invalid (non-existent) plugin; successfully defers and is thrown once config is deemed invalid.

Instructions to run the tests are available in the PR. Will open a PR to upstream if requested.

[aaronjamt]

I'll add my +1 on this, I'd love to stop seeing errors on boot while plugins load. I doubt vaxry will see this here, so personally I'd just open the PR and let him close it if he doesn't agree.

[dskvr]

I've already bothered him enough. If this gets enough upvotes eventually someone will share it with him.