activities and locking
Chani
chanika at gmail.com
Fri Sep 24 13:36:22 CEST 2010
[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...
More information about the Plasma-devel
mailing list