Closed Kibbitzer closed 10 months ago
Yeah I see the problem good point, because currently I am only reloading the icon when the "save" button is pressed in the settings.
I am hesitant to implement this though, because I fear this will open a huge can of worms with potential bugs and issues.
The only way to get the information needed is using the org.freedesktop.portal.Settings
portal.
Sadly portals are horrible to work with and not only does every desktop environment implement them differently, but they are also very unreliable (see pinned issue, all caused by portal nonsense).
Yeah, I understand the implications behind dealing with portals.
In this case, couldn't implementing a command or a job to listen to config changes be a feasible solution then?
So I just pushed a new version, which does a mix of both options. (should be on FlatHub in around 4h)
I did implement the settings portal to request the preferred system theme, but I will always fall back to the default in case the request fails.
Secondly I did also add a watcher for the configuration file which will reload the icon if changed. So in your case you have two options:
icon
value in the config to white
or black
as you wishsystem
option for the icon type and re-trigger the portal request by simply doing a touch setting.conf
, which should trigger a configuration reloadThe latter option of course requires an properly working portal implementation so YMMV.
Let me know if that works for you.
Just tested 0.7 by both changing the config's icon
value using sed
and touching settings.conf
, as well as using the system
option and touching the config again, and can confirm both methods work as intended, including the check for the settings portal at launch.
The console outputs are as follows when launching it first in dark mode, then changing it to light in system settings and touching the config file again using a script:
(user@local ~)$ flatpak run com.github.zocker_160.SyncThingy
QIBusPlatformInputContext: invalid portal bus.
watcher running on "/home/user/.var/app/com.github.zocker_160.SyncThingy/config/SyncThingy/settings.conf"
running inside Flatpak
requesting system theme
got answer: 1
Using Icon: "com.github.zocker_160.SyncThingy.white"
Ping endpoint: "http://127.0.0.1:8384/rest/noauth/health"
Requesting background permission...
reply: QJsonDocument()
syncthing is not running
Syncthing does not seem to be running, starting own instance
/app/bin/syncthing
Background / Autostart permission granted
settings changed
running inside Flatpak
requesting system theme
got answer: 2
Using Icon: "com.github.zocker_160.SyncThingy.black"
As of now, 0.7.1 isn't available on flathub yet.
Edit: Shouldn't make a difference as long as portals are working properly, but I am currently using KDE Plasma 5.27.5.
Thank you for confirming. There is still something really weird going on (which I tried to fix in 0.7.1, but I think it is still not correct).
When you are in dark mode, does the portal return 1 or 2? (I think according to your log it returns 1 in dark mode and 2 in lite mode right?)
This is really messed up (as I sadly expected with the portal), because according to the documentation "1" means "prefer dark appearance", but if you are in dark mode, the icons should actually be white, otherwise you have black on black, which is sadly what is happening on the SteamDeck, where it is actually the wrong way round, but in your case it seems to be correct?
Exactly.
2
Corresponds to Light/Day mode, and 1
to Dark/Night mode.
Current output when using the Light/Day system theme:
requesting system theme
got answer: 2
Using Icon: "com.github.zocker_160.SyncThingy.black"
2 Corresponds to Light/Day mode, and 1 to Dark/Night mode.
Good, this is how it should be.
Current output when using the Light/Day system theme:
You must already be on 0.7.1 then because there 2 loads the black icon and 1 the white one, I hope that is the right way round.
Seems to be working correctly now on Steam Deck and "normal" KDE. Only problem I encountered are the themes, which mix dark and lite theme, but there is nothing I can do about that, as I cannot check the actual background color of the task bar.
So closing as completed.
Reason: Tray icon does not automatically change with the desktop's theme
Suggestion: Having an option to change the tray-icon with a command or implementing a routine to automatically change it based on desktop theme.
Workarounds tried: I set a cronjob to automatically change the
icon
value on the.conf
file by running a simple sed command, but the application does not listen to changes in the config, requiring the user to manually change the setting from the Settings menu, which defeats the purpose of changing the config file directly.