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