Monitor configuration is not persistent

[Flexksx]

You cannot save or load on-device profiles to quickly switch through them.

This is a nice feature that would mimic other monitor layout tools that save your last config per monitor-connections.

A use case is that for example I have a monitor layout for my home office and another one at my office and I really dont like having to open the app each time just to adjust them, ideally that would happen automatically by watching the connected displays and restoring last profile used with a certain configuration.

But that would require daemonizing a part of it, for now just having quick presets at hand does also make it and will make it very useful

[nwg-piotr]

Will "Save current configuration as a profile" / "Restore from a saved profile" do the job?

[Flexksx]

Yes I think so
I can propose my help since I have to do a university assignment and I didn't want to do the original one so I agreed with the professor that I can add this feature as for the assignment)
So if you agree it'd be a win-win-win situation 😉😄

[nwg-piotr]

Of course. PRs are much better than feature requests. :)

[Flexksx]

Ok cool then)

I think a general design of how could this be done is serializing the monitors in json and save them in $HOME/.config/nwg-displays/profiles/profile_name.json

This is a very simple and efficient way of doing it.
There is one thing though, serializing it into per-system specific outputs could become problematic.
I have played around with it and was able to refactor the logic into some base Monitor and HyprlandMonitor and SwayMonitor models, services, and same for the workspace rules (for hyprland for now) which can then help easier serialization and deserialization through a unified interface which can then be decorated with per-compositor specific data.

Moreover, calling hyprctl monitors -j all now shows mirror monitors and some other data that can be useful and ease the integration.

But I'd like to know your opinion too

[nwg-piotr]

I wonder if you could avoid having separate logic for sway and Hyprland, just in case we would like to add support for another compositor in the future. If I remember well, output properties in the DisplayButton class are common for both compositors. Couldn't we just save them to json and then restore from a profile file?

[Flexksx]

yeah I meant logic only in instantiating the monitor configuration as it is currently done in the outputs_dict, not have separate render logic for the app itself.
This will make thing even easier if we want to add a new compositor support, where we would just have to add some classes that implement them and adhere to a Monitor interface which the UI will work with.

My thought for the Monitor interface was having it save generic information like name, model, make, width, height and have a method like to_config_str that would abstractize writing the hyprland or sway config lines into a unified interface

[Flexksx]

and this way its easier to serialize Monitors instead of potentially separate serializations for hyprland or sway

[dhia-gharsallaoui]

That would be a great feature—I’ve been looking for it here. Any updates @Flexksx ? If you need help, I’m happy to assist.

[Flexksx]

Hi! I am currently loaded with a bunch of work both from work and from uni, but I hope to get get it done in the weekend. You could take a look at the version in this PR, I have started a refactor of the project because it was very hard to navigate and understand the code.

You could really help with that if you want, I am running it on NixOS so I have just to run nix run, could be different in your case.

[Flexksx]

#89