Bug 511377

Can confirm.

Hm. So. The CLI tool is a different way to set wallpapers, not a different interface for the same config. Notably you'll also observe that the fill mode is entirely controlled by the CLI and also not honored from the KCM. Given this pre-existing behavior I find it hard to justify honoring the KCM for the light vs dark scenario. That said, there is no way to control light vs dark from the CLI right now... which is indeed a problem.

> The CLI tool is a different way to set wallpapers

Just a reminder there is also the 'wallpaperPlugin' as part of the Plasma scripting API cf. https://develop.kde.org/docs/plasma/scripting/api/#desktops and this also doesn't follow the setting, although i'm not sure if i understand what you mean. I think it shouldn't matter - there are Plasma configurations and these aren't merely entries in some particular drop-down field. I mean there are also UI-less configuration systems, that is, the once where the user has to edit large text files manually to change the settings which is less convenient but the same thing. In the end the configurations are stored in text files and in the Plasma scripting API you can access these for instance the color scheme like so
~~~
    const config = ConfigFile('kdeglobals');
    config.group = 'General';
    config.readEntry('ColorScheme');
~~~
so i wouldn't know why the configurations shouldn't be available - even less so from the C++ level.

> In the end the configurations are stored in text files and in the Plasma scripting API you can access these for instance the color scheme like so

Yeah, from a glance that doesn't seem true. Light vs dark is a flag on the URI of the image. It's not an explicit setting, which is why it gets overwritten when applying the wallpaper using the CLI.

Yes there must be some logic to determine the full image path (if not given explicitly) and this logic has to be adapted to follow the new configuration settings for the wallpaper. This was overlooked, nothing more.

(In reply to Joerg Fischer from comment #5)
> Yes there must be some logic to determine the full image path (if not given
> explicitly) and this logic has to be adapted to follow the new configuration
> settings for the wallpaper. This was overlooked, nothing more.

Well, yeah, I wasn't even aware that there is such a tool. So we have one config but two different paths to change. Whether light or dark or dynamic wallpapers are used depends on the fragment in the URI, but there is also an option to keep user's overall preference. The URI contains wallpaper variant info because it simplifies wallpaper plugin bits quite a bit.

Circling back to `plasma-apply-wallpaperimage`, I guess it could look at that option and append #day-night and so on. In long term, I think it would be nice to unify how various settings are changed, maybe provide some system configuration C++ APIs in libkworkspace. I encountered a similar problem while looking into global themes, various bits are scattered all over the place (and there is also code duplication).

two different paths to change it*

In 6.4 the command `plasma-apply-wallpaperimage /usr/share/wallpapers/Next` picked either the light or the dark variant just like it does now. The only difference is that in 6.4 this choice was done according to whether the color scheme was interpreted as light or dark. In 6.5 it does the same thing only instead of deciding by color scheme it decides by plasma style. The problem with this is that in 6.5 there are configuration options for the wallpaper not present in 6.4. Following the plasma style is only one of these new settings.