[Development] MouseArea: updating hover state when the area moves

[Knoll Lars]

On 8/21/13 7:14 PM, "Alan Alpert" <416365416c at gmail.com> wrote:

>On Wed, Aug 21, 2013 at 8:31 AM, Josh Faust <jfaust at suitabletech.com>
>wrote:
>>
>> On Tue, Aug 20, 2013 at 12:44 AM, Nils Jeisecke <njeisecke at saltation.de>
>> wrote:
>>>
>>> On Tue, Aug 20, 2013 at 6:15 AM, Josh Faust <jfaust at suitabletech.com>
>>> wrote:
>>> >I'm curious what the reasoning behind this is. Is it just a
>>>performance
>>> > optimization?
>>> I think so. Currently scene items don't get a notification if their
>>> absolute positioning changes while the relative position to the parent
>>> does not.
>>> See http://qt-project.org/forums/viewthread/10013/ for an older
>>> discussion.
>>>
>>> > I ask as it makes a number of things not work properly when:
>>> >  * The window resizes (e.g. via keyboard)
>>> >  * A MouseArea (such as a button) moves out from under the mouse
>>> * MouseOver highlights don't disappear. This is very annoying in
>>> ListViews when using the mouse wheel.
>>
>>
>> That's too bad. It mostly causes minor graphical artifacts, but once you
>> start to notice its effects it's everywhere.
>>
>> QtQuick devs: is this being looked into at all? If I can find a solution
>> that has minimal performance impact would it be considered?
>
>It's not being looked into right now. Since QtQuick positioning is
>based on relative parent transforms this limitation fits in quite
>naturally and there is no obvious way around it (with minimal
>performance impact).

I am not sure that's true. For items that take input focus, we also keep
the position updated for input methods (virtual keyboards). I think a
similar mechanism could possibly be used here.
>
>A solution with minimal performance impact would be considered, as
>there's nothing conceptually invalid with knowing when your absolute
>position changes, or having a more accurate hover state. However
>significant behavior changes may not be possible until the next major
>version. Fixing this specific detail of MouseArea might require a flag
>or similar to get changed behavior in the current major version.

We don't need to notify the scene item generally, but we could most likely
keep track of hovered mouse areas without a large performance impact. And
I don't see fixing the overstate to be accurate in this case as a huge
behavioural change.

Cheers,
Lars