FR: independent implementation of persistent layout

[midirhee12]

Motivation

At the moment, development for integrating with kanshi, way-displays, and/or other solutions has stalled. Also, it may be beneficial to have an in-house solution anyways to avoid enforcing another runtime dependency for those who solely use wdisplays. This would be attractive for multiple reasons:

• reduced complexity on package maintainers for less runtime dependencies
• reduced burden on wdisplays's maintainers by avoiding the need to track if either kanshi, way-displays, or other solutions have made breaking changes requiring to change wdisplays to maintain said integrations
• reduced technical debt by having to only develop one set of configuration reader/writer instead of multiple for both kanshi, way-displays, and/or other solutions
• reduce required storage for installation and use (only slightly but still true)
• reduce memory overhead by only requiring one process to be loaded in memory (only slightly but still true)
• reduce CPU usage by reducing context switching (only slightly but still true)
• simplify the ability to integrate with these tools in the future, if so desired, since a configuration reader/writer would have already been made

This is probably important since it is currently required for the user to re-invoke wdisplays and reconfigure their output layout every time an output is disconnected, the wayland compositor is restarted, or the device is rebooted. For laptop users, this is a daily process. And for those sharing monitors between devices (ie - KVM switch users), this is a constant problem. This extends to those screen sharing as the display does come back on when the display is switched to output to the current device again. If a persistent layout configuration was made, this would be a non-issue.

Solution

The data should be dumped into a XDG respecting directory in a user readible / writable format such as JSON, XML, TOML, or similar. The file would be written after the user hits "apply" or a separate save button. A command line flag should exist which can be invoked to read the generated configuration and load the data into wdisplays at start up.

I think the preferred location of the configuration would be either ~/.local/state or ~/.config, but I'm not entirely sure since this would be program writable at any point.

Tasks

Tasks to completed for this feature request:

• Configuration reader (ie - JSON, TOML, etc)
• Configuration writer (ie - JSON, TOML, etc)
• Command line flag parsing
• Start up with data from configuration file
• (Optional) save button in GUI

Note - I'm willing to work on this.

[alex-courtis]

Alex from way-displays here: this sounds incredible! Let me know if you have questions or need some assistance.

reduced burden on wdisplays's maintainers by avoiding the need to track if either kanshi, way-displays, or other solutions have made breaking changes requiring to change wdisplays to maintain said integrations

way-displays interface is additive only: cfg.yaml, CLI and IPC interfaces will not be changed in a breaking manner, only ever added to in a compatible manner.

Configuration writer

Forgive me if I'm stepping over bounds; I've had great success on several projects with yaml-cpp for parsing and rendering in very few lines of code.