Some output data is not setup/configuration specific, but rather is meant to be saved for the output in every possible configuration. Currently there are:
Implement a per-output storage pool for these data values and logic to use either this data or more specified per-config data.
When user changes properties in KCM, he might either decide to change data for the current configuration only or set it as new "default" for this output on every configuration, which does not overwrite with configuration-specific values. How should this be communicated to the user and how should he switch around for his current config operation?
Default should be that data is retained on a per-output basis.
Simple solution draft: Checkbox
[] Save for this setup only.
or
[X] Use for all setups with this display.
VDG input desirable.
[] Save for this setup only.or
[X] Use for all setups with this display.
I would say:
Save for: [X] only this display
[] all displays
In regards to backend I hit a wall in that the variable value if properties of a display should be saved for all configs without override or only for the current one need to be communicated between the KCM and the daemon. The communication mostly uses the kscreen backend though, which means it is tunneled through the Wayland compositor or XCB.
It does not make much sense to add a new property on this route. Instead I want to do the following now:
Split up the directory $HOME/.local/share/kscreen into directories individuals, configs and control/configs. The text files from the kscreen directory will be moved to the configs directory. To the individuals and configs directory only the daemon writes. The daemon only reads files from the control directory, which other processes can use to provide the daemon with additional information.
In the case of control/configs the KCM would write into a file with the name of the config hash if the output properties are saved/loaded from this config only or from/to the individuals directory.
There is one other special case: a configuration with several identical displays. We maybe want the individual output data globally to be overridden, but keep the output values different in this specific configuration.
In this very specific case it might make sense to not allow interacting with the global output value in general if configuration specific values exist, but only load/write these instead.