KDE/kdebase/workspace/plasma/desktop/shell

[Chani]

On Monday, June 28, 2010 02:29:41 pm Marco Martin wrote:
> SVN commit 1143845 by mart:
> 
> avoid a crash in the following scenario: change the activity type of a
> containment, then try to stop the activity. it still misbehaves, because
> the new containment it gets created is not added to the activity and the
> activity manager, that will list the activity as stopped. this should be
> backported, but it has to be "right" before :)
> CCMAIL:plasma-devel at kde.org
> 
> 
>  M  +16 -0     activity.cpp
>  M  +1 -0      activity.h
> 
> 
> --- trunk/KDE/kdebase/workspace/plasma/desktop/shell/activity.cpp
> #1143844:1143845 @@ -315,8 +315,24 @@
>      connect(context, SIGNAL(activityChanged(Plasma::Context*)), this,
> SLOT(updateActivityName(Plasma::Context*)), Qt::UniqueConnection);
> 
>      m_containments.insert(QPair<int,int>(screen, desktop), containment);
> +    connect(containment, SIGNAL(destroyed(QObject *)), this,
> SLOT(containmentDestroyed(QObject *))); }
> 
> +void Activity::containmentDestroyed(QObject *object)
> +{
> +    //safe here because we are not accessing it
> +    Plasma::Containment *deletedCont = static_cast<Plasma::Containment
> *>(object); +
> +    QHash<QPair<int,int>, Plasma::Containment*>::iterator i;
> +    for (i = m_containments.begin(); i != m_containments.end(); ++i) {
> +        Plasma::Containment *cont = i.value();
> +        if (cont == deletedCont) {
> +            m_containments.remove(i.key());
> +            break;
> +        }
> +    }
> +}
> +

hmmm. I did think there was a convenience function for removing a value from a 
hash. but anyways...

double-check how the *new* containment is being added, too. it really ought to 
have been replacing the old one in the hash. hmm, but iirc aaron's code didn't 
do anything special and my code wasn't designed to let things be overwriten, 
so... 

erg, well, I can't find the code aaron added, but *iirc* it was using 
insertContainment, which will refuse to overwrite, because it used to be (and 
miight still be but hopefully not) possible to end up with two containments 
both wanting to be on that same activity and screen and desktop. you could 
either rewrite that one to reject the old containment instead of the new one, 
or write a separate swapContainment function.. eh, don't make a new function, 
just change the existing one, it doesn't matter which one wins when there's a 
conflict on startup :)

also, maybe that hash should be using weak pointers? *shrug*