On Mon, Sep 19, 2016 at 7:10 PM, Marco Martin <notm...@gmail.com> wrote:
> On Mon, Sep 19, 2016 at 7:55 PM, David Edmundson > <da...@davidedmundson.co.uk> wrote: > > https://bugs.kde.org/show_bug.cgi?id=365967 > > > > It's a bug in that weather applet that it's rendering outside the area it > > actually has - and that needs fixing anyway. > > Introducing a new form factor won't solve that - in both cases you have > to > > do the exact same amount of work to that applet. > > yes, just needs something for the applet to check (which at the moment > doesn't have) i don't think it's fixable completely from systray side > (most one could do, is clipping, which I would like to avoid) > > >> IndicatorArea formfactor would have a Mutable immutability°, because > >> the systray itself should always be able to both add and remove > >> plasmoids in itself even when immutable (even Systemimmutable) it > >> could still hide/disable the ui to do so when immutable, but must be > >> programmatically able to do so. > > > > > > 365618 and 365569 are basically the same thing right? > > yes, same thing, entries not getting removed when locked. > > > You're saying we need mutability to be different in system tray > containment > > compared to it's parent. Sounds fine. +1 > > > > But I don't see why we would tie that to the formFactor. > > Semantically they're not remotely related, the only link is that the > system > > tray happens to need both. > > perhaps you are right, semantically they are two things, not sure what > could be used instead more "proper"(suggestions welcome), will think > more about it. > Long term, a virtual hook for immutability? > also, what do you suggest for 5.8? trying to temporarly unlock? > We can try it. This also works: applet->pluginInfo().pluginName()) { - applet->destroy(); + QMetaObject::invokeMethod(applet, "cleanUpAndDelete"); (in all 3 cases) But it's equally messy, and has an issue that transient won't get set, so I don't like it. -- > Marco Martin >
