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:
Note - I'm willing to work on this.
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 usewdisplays. This would be attractive for multiple reasons:wdisplays's maintainers by avoiding the need to track if eitherkanshi,way-displays, or other solutions have made breaking changes requiring to changewdisplaysto maintain said integrationskanshi,way-displays, and/or other solutionsThis is probably important since it is currently required for the user to re-invoke
wdisplaysand 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
wdisplaysat start up.I think the preferred location of the configuration would be either
~/.local/stateor~/.config, but I'm not entirely sure since this would be program writable at any point.Tasks
Tasks to completed for this feature request:
Note - I'm willing to work on this.