[this is a summary of an irc discussion today...] so, I finally found out how to reproduce the elusive activity-duplication bug. :) it happens when plasma is locked: stopping the activity copies its config out to a separate file, then tries to remove it from plasma-desktop-appletsrc, but Applet::destroy() ignores attempts to delete the containment and its applets.
now you've got two copies of the containment(s) - and when plasma-desktop is restarted, it finds this extra containment and "helpfully" creates a new activity for it so that it's accessible. it doesn't matter whether you delete the activity, it's the stopping that's the cause. and while one may question whether deleting should be allowed while locked, stopping while locked makes perfect sense. what we're going to do about this in trunk: the code for the activity stopping will be moved into Corona under a name like exportLayout (to mirror importLayout). it won't actually know about activities, it'll just know that a certain bit of config needs exporting to a certain file. it'll temporarily unlock the corona so that it can do its work in peace, and restore the old setting when it's done (this is something that can only be done within corona if SystemImmutable is on). that new API is a bit much for backporting, though, so in 4.5.2+ the UI won't allow closing or deleting while widgets are locked. aaron's gonna put in some pretty UI for that. :) note to self: wtf is Activity::save() doing there? it looks like stale code that needs deleting... and destroy()'s deletion of running containments is redundant so long as we only allow deleting stopped ones, but oh well... _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
