| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
| |
Added the needed macros around the classnames the way it
should be done.
Reviewed-by: Prasanth
|
| |
|
|
|
|
|
| |
After we implemented hitTest for QCocoaView, this function is no longer
used.
Reviewed-by: Norwegian Rock Cat
|
| |
|
|
|
|
|
|
|
|
|
| |
Drag and drop events should consider the WA_TransparentForMouseEvents
attribute like the mouse events. If this attribute is set for a widget,
the event has to be passed to right widget under mouse. The widget is
identified by calling hitTest. In such cases the leave event has to be
delivered to the widget which actually accepted the enter event.
Task-number: 252088
Reviewed-by: Norwegian Rock Cat
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cocoa calls hitTest on our view to determine if
the view should get the mouse press. We always
said, "yes" and did all the logic ourselves. Turns
out that we can say "no" if I'm transparent to
mouse events and remove all that code where we do
all the work ourselves. Big maintenance win!
For the time being I've kept the
"transparentViewForEvent" method since it might be
useful for others, but no one is using it at the
moment and we may just kill it soon. HitTest should
handle this situation correctly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tracking of mouse events was only enabled when enableMouseTracking or
Hover or a tooltip had been set explictly on the item, but this meant
that the dynamic QEvent::Tooltips would never get dispatched. So, in
order to help out people that might use this feature, all QCocoaViews
must pay the mouse move event tax *sigh*.
I added comments in the proper places so that we DO the right thing for
a release where we can force the change in behavior.
Task-number: 257320
Reviewed-by: Denis
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
| |
Reviewed-by: Richard Moe Gustavsen
|
| |
|
|
|
|
|
|
|
|
|
| |
There was some strangeness happening here with parents, but the main
problem was the fact that wheel was getting sent to the focusframe and
not to the widget below. However, the focusframe has the "transparent
for mouse events" flag set and wheel events probably should be
transparent as well.
Task-number: 253539
Reviewed-by: Richard Moe Gustavsen
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We were registering the types each time drag and drop was enabled, which
caused slowdowns when for example switching between the Edit and Debug
modes in QtCreator.
Instead, register the types on first enable and also when the custom types
change. Add check to draggingEntered() that disables the drag if
WA_DropSiteRegistered is false.
Reviewed-by: nrc
|
| |
|
|
|
|
|
|
| |
Argh! Copy and paste is evil, not only was the test was wrong, We sent
the event twice and the second time we sent the wrong value.
Task-number: 250668
Reviewed-by: Morten Sørvig
|
| |
|
|
|
|
|
|
|
|
|
| |
In the updated examples, the drag operation is changed in the drop-event
handler, which was not handled correctly in the Cocoa. This is now
supported for drag and drop from same application. If the drop was to
another application, the drag will return the result from the last
drag-move event.
Task-number: 252103
Reviewed-by: nrc
|
| |
|
|
|
|
|
|
|
|
| |
Our "view under tranparent view" function was sound, but it didn't take
into consideration that fact that views in the hierarchy could be
hidden. This is most prominent when you have a QFocusFrame over a
QAbstractScrollArea.
Task-number: 251008
Reviewed-by: Morten Sørvig
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The NSOpenGLContext seems to be tied to the window. So if the view
changes from one window to another, the OpenGL context needs to be
cleared. We can do this by hooking into the viewWillChangeWindow and
viewDidChangeWindow events and clear and reset the drawable
respectively. We also found out that QCocoaOpenGLView was not being used
at all, so just remove it to get rid of any confusion.
Task-number: 250066
Reviewed-by: Trond
|
| |
|
|
|
|
|
|
|
|
| |
Cocoa has a different way of dealing with cursors than our heavy handed
approach that we used in Carbon. We simply need to re-implement the
proper function in NSView and set up the rectangles for the cursor
correctly. We also need to expose an QCursor2NSCursor type functions
since the current QCursor::handle() is useless for doing this and we
shouldn't change that. With this change things seem to work much more
like the native stuff for both Carbon and Cocoa.
|
| |
|
|
|
|
|
|
|
| |
the Cocoa Builds.
The drag move events were compressed based only on the position of the
cursor. It has to be based on both position and the "drag operation" in
native event.
Reviewed-by: nrc
|
| |
|
