FR: independent implementation of persistent layout

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.

artizirk / wdisplays