branches/KDE/4.1/kdebase/workspace/libs/plasma

[Ambroz Bizjak]

Ambroz Bizjak wrote:
> Aaron J. Seigo wrote:
>> On Monday 18 August 2008, Ambroz Bizjak wrote:
>>> SVN commit 849036 by abizjak:
>>>
>>> Fade applet handle back in if the mouse reenters the applet while it's
>>> already fading out.
>>
>> cool; you have an svn account now! =)
>>
>> note that i didn't backport this change because:
>>
>> * it's not particularly critical
>>
>> * there is some problem currently in trunk where *sometimes* a ghost
>> handle
>> gets created (easiest to replicate when zoomed out) and then you can't
>> move
>> the actual applet anymore; i haven't had time to track down the issue,
>> and
>> i
>> was concerned it might have something to do with this patch
>>
>> so if you could, please revert this commit to the 4.1 branch at least
>> until we
>> get the handle issues sorted out in trunk ..
>
> Yes I have noticed some problem. Sometimes the applet would not follow the
> handle when you move it. It happens if the mouse reenters the applet in
> around the same time the handle disappears.
> However I can reproduce that on 4.1, both with and without my patch, and
> with and without zooming out. I think it has nothing to do with my fix.
> Another thing I have stumbled upon: the handle once disappeared and would
> not reappear at all (but this was without my fix); no idea when it
> happens.
>
> Though if you meant some other problem, or if you still think my fix
> should be reverted, say so. I think you have only noticed the problem now,
> but it was there all along; because I have noticed the first problem I
> described quite some time ago.

Both of the symptoms I described happen when two applet handles are
attached to the same applet (very rare!).
When a handle disappears, it emits AppletHandle::disappearDone and
triggers ContainmentPrivate::handleDisappeared, which removes it from its
list of handles and calls deleteLater on it. For some reason, if the
cursor reenters the applet exactly the time the handle disappears,
immediately after that the mouse enter event triggers
Containment::sceneEventFilter, which creates a new applet handle -
before(!) the previous handle is automatically deleted. The two seem to
conflict and exhibit weird behavior.

A solution would be to wait until the handle is actually deleted and then
create a new one if needed. I'll try to code a fix tomorrow.