[Interest] OS X Qt 5.2/5.3 keyboard modifier bug

[Etienne Sandré-Chardonnal]

>
> I would suggest capturing the key presses at an upper level (such as the
> MainWindow) and change the child widget mouse cursor accordingly with
> setCursor. This way, the behavior is independant from focus, does not
> require mouse tracking, and does not require the cursor to be over the
> widget when the key is pressed.
>

The thing is the cursor should only change when the mouse is in the window,
since it's related to direct manipulation of objects in the widget, not
elsewhere in the UI, so I believe my current workflow is correct. Trapping
the modifier at a higher level would break encapsulation as well.

No, if you use childWidget->setCursor, it will set the cursor for this
widget only. I'm not talking of QApplication::setOverrideCursor


>
> Whether it's "right" or "wrong", this code has worked for 10 years, and
> broke in 5.x.
>

1)If you don't set focus, the doc says that it will not work. If it did
before, that's a bug which was fixed.
2)Setting the focus on mouse enter is a GUI design flaw. Just loosing a
text box input focus because the mouse is moved can be very frustrating for
the user (I've seen it on an industrial app, and users were complaining
about it).

Cheers,

Etienne


2014-04-04 17:17 GMT+02:00 Paul Miller <paul at fxtech.com>:

> On 4/4/2014 10:01 AM, Etienne Sandré-Chardonnal wrote:
>
>> Do you have mouse tracking enabled on this widget? Otherwise you can't
>> detect when the mouse enters the widget.
>> I'm not sure that you implement it the proper way. Changing the mouse
>> cursor when a modifier key (eg Ctrl) il pressed should not be done with
>> the widget keyPressEvent, as this will not work if the user presses the
>> key when the mouse is outside, then enters the widget. Also,
>> keyPressEvent only works with focus, which is not what you want.
>>
>
> Yes, mouse-tracking is enabled. It's a viewer type widget with
> direct-manipulation stuff. I call setFocus() when I get mouseMove events.
> Once I click in the widget, it starts working as expected.
>
>
>  I would suggest capturing the key presses at an upper level (such as the
>> MainWindow) and change the child widget mouse cursor accordingly with
>> setCursor. This way, the behavior is independant from focus, does not
>> require mouse tracking, and does not require the cursor to be over the
>> widget when the key is pressed.
>>
>
> The thing is the cursor should only change when the mouse is in the
> window, since it's related to direct manipulation of objects in the widget,
> not elsewhere in the UI, so I believe my current workflow is correct.
> Trapping the modifier at a higher level would break encapsulation as well.
>
> Whether it's "right" or "wrong", this code has worked for 10 years, and
> broke in 5.x.
>
>
>> Etienne
>>
>>
>> 2014-04-04 16:20 GMT+02:00 Paul Miller <stelefx at gmail.com
>> <mailto:stelefx at gmail.com>>:
>>
>>
>>     Here is another regression I found that is a show-stopper for us.
>>
>>     In a custom widget I have a keyPressEvent() and keyReleaseEvent()
>>     handler to update a cursor when modifier keys are pressed (such as
>> Cmd).
>>     In Qt 5.x, pressing Cmd (or shift, or ctrl) causes no keyPressEvents
>>     UNTIL the user clicks on the widget. Manually calling setFocus() on
>> the
>>     widget when the mouse enters it doesn't help either.
>>
>>     This all worked before 5.x.
>>
>>     I can't be the only one to find this can I?
>>     _______________________________________________
>>     Interest mailing list
>>     Interest at qt-project.org <mailto:Interest at qt-project.org>
>>     http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140404/a1a26ada/attachment.html>