Bug 505792

Summary: Updating to 6.4.0 enables weather report system tray item
Product: [Plasma] plasmashell Reporter: EpicTux123 <EpicTux123>
Component: System Tray widgetAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED INTENTIONAL    
Severity: normal CC: cwo.kde, isma.af, materka, nate
Priority: NOR    
Version First Reported In: 6.4.0   
Target Milestone: 1.0   
Platform: Fedora RPMs   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=480781
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description EpicTux123 2025-06-19 16:14:58 UTC
Updated to 6.4.0 and weather report system tray was re-enabled, even though I had it disabled before the update.

Operating System: Fedora Linux 42
KDE Plasma Version: 6.4.0
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.14.11-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Comment 1 EpicTux123 2025-06-19 16:17:05 UTC
Well, this is weird. In the system tray settings, I have "Always show all entries", and now everything is "Shown when relevant" whereas before I could set some to "Disabled".

Now I can't touch any of them, including weather report. So it is permanently there.
Comment 2 cwo 2025-06-19 17:52:41 UTC
The weather applet was changed from default disabled to hidden. I don't think this should enable it for people that had manually disabled it, but I'm not quite sure how the logic works here to be honest - the way this information is saved is relatively complex.

The ability to disable Plasmoids was removed as part of the change to allow disabling SNIs:

https://invent.kde.org/plasma/plasma-workspace/-/commit/13a2b93ec46bc529e5f95cadd58e2b359626dcd3#3254ca61bf5876b6c2651bd3ff495f5e332c72ff_163_195

Nate, was this intentional or an accidental change?

In any case, disabling still seems to work - if you disable "Always show all entries", set the entry to disabled, then enable "Always show all entries" again (and Apply of course) it'll display the entry as "Shown when relevant", but it won't be in the tray.
Comment 3 Nate Graham 2025-06-19 20:46:26 UTC
Since Weather Report was disabled by default before, changing the new default setting to something else was intentional in this case. The whole point was to surface it as something you can interact with, without having to go digging around in the settings window.

So that part is "RESOLVED INTENTIONAL".

Plasmoids should still be able to be disabled, and I can still do that on my git master system. Are you unable to?
Comment 4 cwo 2025-06-19 21:08:49 UTC
(In reply to Nate Graham from comment #3)
> Plasmoids should still be able to be disabled, and I can still do that on my
> git master system. Are you unable to?

I can normally, but not when "Always show all entries" is enabled. 

In 6.3:

- When "Always show all entries" is disabled, the combobox is enabled, and choose between all visibility levels (but not disable SNIs)
- When "Always show all entries" is enabled, SNIs have the combobox disabled, and plasmoids have it enabled with a limited set of choices: only "Show when relevant" and "Disabled". "Show when relevant" shows them always, Disabled has them disabled

In 6.4:

- When "Always show all entries" is disabled, the combobox is enabled, and I can choose between all visibility levels (even disable SNIs)
- When "Always show all entries" is enabled, both SNIs and Plasmoids have the combobox disabled and display "Show when relevant". You can't switch the settings for plasmoids anymore. But if you set one to visibility "Disabled", it remains off, even though the (itself disabled) combobox shows "Show when relevant".

I'm not even sure what the correct behavior should be ("Always show all entries" not always showing all entries in 6.3 also seems weird, but it might be that the behavior is correct and the wording is awkward and should be something like "Always show all entries unless manually disabled"). But the current behavior does seem wrong.

(I had no idea 6.3 worked this way, but luckily I didn't update my Fedora package yet and could test it out... I did test various circumstances while doing the testing for the unsaved changes implementation in the system tray, but that was after the above commit so already with the new behavior).
Comment 5 Nate Graham 2025-06-20 16:39:11 UTC
I admit didn't test with "Always show all entries". But with that checked, isn't it doing exactly what you asked it to do? It always shows all entries! If you don't actually want it to always show all entries, then it's not the right feature to be using, and you should instead manually curate entries' visibilities.

> But if you set one to visibility "Disabled", it remains off, even though the (itself disabled) combobox
> shows "Show when relevant".

This part seems like an actual bug; everything else seems like intentional behavior to me.
Comment 6 cwo 2025-06-20 17:55:59 UTC
(In reply to Nate Graham from comment #5)
> I admit didn't test with "Always show all entries". But with that checked,
> isn't it doing exactly what you asked it to do? It always shows all entries!

Yeah, that made sense to me when I tested things (but I didn't test keeping something disabled first, then checking that).

But it was different in 6.3, where you could choose "show" and "disabled" while the setting was active. And that somewhat makes sense too, and it seems some users made use of this (if they want to never have any entries in the hidden section, but completely turn off some irrelevant ones).

It's a reasonable interpretation of what a setting named "Always show all entries" should do, but arguably it's not as broadly useful as the original interpretation. I'm ok with keeping it this way, but I wanted to check in (that's why I asked if this change in behavior from 6.3 to 6.4 was intentional).
Comment 7 Nate Graham 2025-06-20 18:07:30 UTC
It sounds like we accidentally fixed a bug, then — a bug that people had been relying on! But it's not something that I think it makes sense to restore, as it somewhat goes against how the feature advertises itself. People who don't actually want to see all icons can curate their preferences manually.
Comment 8 EpicTux123 2025-06-20 18:18:30 UTC
I disagree. I do exactly what it is told in https://bugs.kde.org/show_bug.cgi?id=505792#c6. I use "Always show all entries" and then hide some irrelevant ones because I don't like the hidden menu. The way it was before made sense to be, where everything was "Shown when relevant" and I still could disable some entries manually. Is there a middle-ground we can achieve here? Thanks.
Comment 9 Nate Graham 2025-06-24 21:10:30 UTC
"Always" means "always." The idea of a setting that says "Always do X" but lets you make "always" not always mean "always" isn't coherent.

If you don't actually want the "always" behavior, there's a pre-existing method to register that preference that you can use instead.
Comment 10 cwo 2025-06-24 21:47:49 UTC
(In reply to Nate Graham from comment #9)
> "Always" means "always." The idea of a setting that says "Always do X" but
> lets you make "always" not always mean "always" isn't coherent.
> 
> If you don't actually want the "always" behavior, there's a pre-existing
> method to register that preference that you can use instead.

The alternative would be to rename the setting.

There was specific code to have this capability, so it seems clear that this is the feature as originally intended. The original bug 349812 and the kconfig setting description all seem to imply that it's really intended as a setting "never hide things (i.e. put them in the popup instead of the tray immediately)" (though that has an awkward semantic double negative) with a slightly ill-fitting name.

We could of course change the feature to completely match the name, but the original behavior might be strictly better - even if someone doesn't like the popup, there are likely some things they do not want to see, and even more so as we add more things to the tray. On the other hand, if they really don't and want to see absolutely every tray icon that Plasma hast, they don't lose anything - they can just not set any to disabled.
Comment 11 Nate Graham 2025-06-25 23:29:32 UTC
So the feature was basically intended to be "don't have an expanded pop-up, so everything is either always visible or always hidden"?
Comment 12 cwo 2025-06-26 05:40:02 UTC
(In reply to Nate Graham from comment #11)
> So the feature was basically intended to be "don't have an expanded pop-up,
> so everything is either always visible or always hidden"?

That's how I understand the original behavior and the feature request that introduced it, which is about it being annoying having to change every new thing that gets added to not hide.

We could certainly change this, but I'm not sure I see a point in the new behavior (at least compared to the old one, which has this particular use case that does seem reasonable).