feat: Niri Service

[regenman]

This PR adds a Niri service, including a sample config.
Based on the hyprland service.

[linkfrg]

I think creating a separate example bar for Niri leads to code repetition and makes these examples harder to maintain

How about adding a check? If running on Hyprland, display the hyprland workspaces, if running on Niri, display the Niri widgets accordingly

[regenman]

I think creating a separate example bar for Niri leads to code repetition and makes these examples harder to maintain

I completely agree.

How about adding a check? If running on Hyprland, display the hyprland workspaces, if running on Niri, display the Niri widgets accordingly

Sounds good. What do you think would be a sensible way to check this, test the existence of NIRI_SOCKET / HYPR_SOCKET_DIR ?

[linkfrg]

Sounds good. What do you think would be a sensible way to check this, test the existence of NIRI_SOCKET / HYPR_SOCKET_DIR ?

Hmmm, or add new properties to Hyprland Service and Niri Service like is_available, or catch exceptions (HyprlandIPCNotFoundError, NiriIPCNotFoundError)...

I'm more inclined to the first option

1. I will add the is_available property to the Hyprland Service in the main branch
2. Merge this change from the main to this PR
3. Add new property to the Niri Service here
4. Add a check to the bar example

EDIT: Better leave HyprlandIPCNotFoundError and NiriIPCNotFoundError, but now they shouldn't be raised during service initialization. Only on requesting operations with socket like switch_to_workspace(), send_command() and etc.
Listening to socket should be skipped if is_available is False

[regenman]

4. Add a check to the bar example

I'm a bit stuck on how to structure the example, in a way that minimizes code duplication. My apologies for being a bit inexperienced with OOP.
In the case of my "working prototype" config.py for niri, I'm passing down "monitor_name" as function parameter all the way from bar()->left()->workspaces()-> .. , reason being that niri indexes workspaces separately per monitor. Without this, with a dual monitor setup, your list of workspaces would be "1 1 2 2 3 3 .." . But passing a "monitor_name" parameter wouldn't necessarily be a useful addition to the corresponding hyprland functions, due to the differences in how it handles workspaces.
Should I just make the whole example a class instead, if I understand it correctly it would allow access to variables across functions?
Any hints or ideas would be appreciated.

[linkfrg]

4. Add a check to the bar example

I'm a bit stuck on how to structure the example, in a way that minimizes code duplication. My apologies for being a bit inexperienced with OOP.

In the case of my "working prototype" config.py for niri, I'm passing down "monitor_name" as function parameter all the way from bar()->left()->workspaces()-> .. , reason being that niri indexes workspaces separately per monitor. Without this, with a dual monitor setup, your list of workspaces would be "1 1 2 2 3 3 .." . But passing a "monitor_name" parameter wouldn't necessarily be a useful addition to the corresponding hyprland functions, due to the differences in how it handles workspaces.

Should I just make the whole example a class instead, if I understand it correctly it would allow access to variables across functions?

Any hints or ideas would be appreciated.

Just make separate functions for niri (move them from the current bar-niri). And add a check in the workspaces() function using the newly added is_available() property. If running on hypland, return hyprland_workspaces() (you need to move hyprland workspaces to separate function), if on niri, returnniri_workspaces(), else return empty Widget.Box

[regenman]

Thank you.
I think I've arrived at a working example. Tested under niri and hyprland, also seems to work as expected when neither of those are available.

[linkfrg]

Okay, looks good

Is it ready for merging or you're planning to add additional functionality or fixes?

[regenman]

Thank you for the fixups.
I'm not planning to add more functionality at this point. In my personal config I've added a simple power menu, but it's unrelated to niri and could perhaps go as a separate PR. I'll mark this as ready for review.

[linkfrg]

Thanks!
Merging...