| davidedmundson |
| Plasma |
be able to destroy applets even when locked: delete their config
by hand.
Except in one case: when the applet gets automatically destroyed
by dbus activation do *not* clear the config, it should be
reused next time.
When there is already a config for a given plasmoid, reuse it
instead of creating a brand new plasmoid (having config groups
endlessy accumulating in the config file)
BUG:365618
BUG:365569
| No Linters Available |
| No Unit Test Coverage |
| applets/systemtray/systemtray.cpp | ||
|---|---|---|
| 139 | I think applet can be null here | |
| applets/systemtray/systemtray.cpp | ||
|---|---|---|
| 136–153 | Is this for the DBus activated case? | |
| 163 | This reintroduces the NetworkManager restarting bug. Applet exists, is still in applets() but now isn't marked as transient as you're not marking it as such. | |
| 394–397 | C++ applets can override cleanupAndDelete You're skipping that. | |
| applets/systemtray/systemtray.cpp | ||
|---|---|---|
| 394–397 | Edit. I was wrong, it is virtual, but private within p-f. Ignore this. | |
| applets/systemtray/systemtray.cpp | ||
|---|---|---|
| 136–153 | not only, actually this case is true for each startup after the first, during normal config restore. This is the branch always executed except when a previously unknown applet is added | |
| 163 | don't know how to properly fix it without changes in p-f tough ( i could still call destroy() in case of mutable, tough when an applet goes away for dbus reasons, its config should actually not be removed (so shouldn't be transient).. | |
| applets/systemtray/systemtray.cpp | ||
|---|---|---|
| 163 | instead of applet->destroyed() i could connect to its destroyed signal and keep a list of deleteLater()ed applets... | |
or could (ouch)manually emit applet::appletDeleted() from the outside that's yeah, horrible but would immediately remove the applet from applets()..
| applets/systemtray/systemtray.cpp | ||
|---|---|---|
| 163 | restarting Networkmanager seems to cause the applet to reload correctly | |
| applets/systemtray/systemtray.cpp | ||
|---|---|---|
| 163 | hm, in that case still seems to create a spurious duplicate config group tough | |
in the latest version restarting networkmanager fully works as expected: it gets restarted and its old config group gets used
Ideally maybe split the m_knownTasks loading and the deletion changes into two commits, they're not entirely related