[Differential] [Changed Subscribers] D4414: don't regenerate frames when setting every property

David Edmundson noreply at phabricator.kde.org
Tue Feb 7 11:14:35 UTC 2017


davidedmundson added inline comments.

INLINE COMMENTS

> framesvg.cpp:136
>  
> -    FrameData *fd = d->frames[d->prefix];
> -
> -    const QString oldKey = d->cacheId(fd, d->prefix);
> -    const EnabledBorders oldBorders = fd->enabledBorders;
> -    fd->enabledBorders = borders;
> -    const QString newKey = d->cacheId(fd, d->prefix);
> -    fd->enabledBorders = oldBorders;
> -
> -    //qCDebug(LOG_PLASMA) << "looking for" << newKey;
> -    FrameData *newFd = FrameSvgPrivate::s_sharedFrames[theme()->d].value(newKey);
> -    if (newFd) {
> -        //qCDebug(LOG_PLASMA) << "FOUND IT!" << newFd->refcount;
> -        // we've found a math, so insert that new one and ref it ..
> -        newFd->ref(this);
> -        d->frames.insert(d->prefix, newFd);
> -
> -        //.. then deref the old one and if it's no longer used, get rid of it
> -        if (fd->deref(this)) {
> -            //const QString oldKey = d->cacheId(fd, d->prefix);
> -            //qCDebug(LOG_PLASMA) << "1. Removing it" << oldKey << fd->refcount;
> -            FrameSvgPrivate::s_sharedFrames[fd->theme].remove(oldKey);
> -            delete fd;
> -        }
> +    d->pendingEnabledBorders = borders;
>  

I'm lost on why we have the pendingEnabledBorders

you have some bugs if you do:

setRepaintBlocked(false);
setEnabledBorders(Left)
enabledBorders() /// returns All not Left.

it'll get updated later but after the changed signal on the FrameSvgItem.

Do we need to know the old borders when we update? If so can we revert this logic to have a d->oldBorders that gets set at the end of the update method?

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D4414

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: mart, #plasma
Cc: davidedmundson, plasma-devel, #frameworks, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170207/41dc9381/attachment.html>


More information about the Kde-frameworks-devel mailing list