| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qcocoaview_mac_p.h
src/gui/widgets/qmainwindow.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There was code for updating the size constrains inside
setConstraints_sys. This is now added. Factored out the code that
does this into a function, and since we never applied size constraines
on a window upon creation, I also added an extra call from that
code part
Task-number: 219695
Reviewed-by: Trenton Schulz
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The reason is that we never applied the new max min values on the
native window itself. This patch does that, and also makes sure that
we do this on the appropriate times (window creation, etc)
Task-number: 219695
Reviewed-by: Trenton Schulz
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The test fails because, in cocoa, when resizing a window to zero (either
w or h), cocoa will also move the window up in the corner (!). So the
fix is to issue an extra move back to it's true location after the
resize. The faulty cocoa move is issued inside the resize callback, so
we choose to not update the window location anymore from a pure resize
callback.
Task-number: 251895
Reviewed-by: Trenton Schulz
|
| |\ \
| |/
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/global/qfeatures.h
src/gui/painting/qtransform.cpp
util/scripts/make_qfeatures_dot_h
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is not strange since we never did anything to limit a resize within
the max min boundries. This patch factores out the code that ensures
this into a private function that is called both as a reaction to a
resize event, but also if resize is done programatically.
Task-number: 251893
Reviewed-by: Trenton Schulz
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
tests/auto/qaction/tst_qaction.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| | |
If we don't have a sheet, we need to recreate it in Cocoa.
Unfortunately, we neglected to reassign the NSWindow pointer in that
case, so the program would crash.
Reviewed-by: Richard Moe Gustavsen
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
tests/auto/qpainterpath/tst_qpainterpath.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The comment in the code pretty much says it all, so I'll repeat it:
This is a workaround for NSToolbar. When a widget is hidden by
clicking the toolbar button, Cocoa reparents the widgets to another
window (but Qt doesn't know about it). When we start showing them,
it reparents back, but at this point it's window is nil, but the
window it's being brought into (the Qt one) is for sure created.
This stops the hierarchy moving under our feet.
Task-number: 251294
Reviewed-by: Prasanth Ullattil
|
| | |
| |
| |
| | |
These aren't used in Carbon, so don't reference them.
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NSPanels are set to hide when the application becomes inactive by
default. This is not what we wan't for normal dialogs in Qt. This
patch makes this setting explicit, in case the window we're about
to create is a dialog.
Task-number: 250869
Reviewed-by: Trenton Schulz
|
| |\ \
| |/
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
src/gui/graphicsview/qgraphicsitem_p.h
src/gui/graphicsview/qgraphicsscene.cpp
src/gui/painting/qtransform.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QWidget::childAt() makes some assumptions about its children (they are
all contained in its geometry). This does not hold up when using the
unified toolbar because the toolbar ends up in the "non-client" area.
So, when dispatching an enter/leave event in tooltip show, we end up
dispatching to the wrong widgets and that results in the tooltip
cleverly thinking that it needs to hide itself because we've left the
widget that needs the tooltip. I've special cased this by just having a
"native" mapFromParent() that is only called for on the mac, though
there is nothing that is limiting this from being called on other
platfroms.
Also QWidget::mapFromParent() probably needs to be looked at at some
point.
Task-number: 248048
Reviewed-by: Richard Moe Gustavsen
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We changed the logic for determining sheets, but it seems we forgot to
take the parentWidget() into account. It's required for WindowModality
to make any sense.
Reviewed-by: Richard Moe Gustavsen
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On Carbon, we did show/hide menubar, on Cocoa we used SetSystemUIMode.
But SetSystemUIMode is available to both, so why not just do that and
make everything consistent. We now act more like other fullscreen apps
(i.e., we show the menu and dock when the mouse is close to them). The
good thing is that it should be easier to override this behavior as
well. I also removed some code in our mouse handler where we were
calling HideMenuBar as I don't see a great reason for it at the moment
in any case, it would be inconsistent between Carbon and Cocoa.
Task-number: 249655
Reviewed-by: Prasanth Ullattil
|
| |/
|
|
|
|
|
|
|
| |
We were using the older CGSSetWindowAlpha function, which really is not
well advertised. Instead, Apple eventually added SetWindowAlpha, but we
neglected to update. May as well do that now skip the wrath of a change
in the private API.
Task-number: 244629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
key events.
We need to be more explicit in setting the first responder, and a bit
more agressing about rejecting it when called with no responder.
It seems that Cocoa has a tendency to reset the first responder when
lots of widgets get hidden or shown. During this it will call
"makeFirstResponder" on the window with a nil responder. Doing this will
reset our what Cocoa thinks is the focus widget, but Qt will still show
a focus widget. The way to solve it is to reject the make first
responder if the responder is nil. I'm not sure if there will be far
reaching implications for this, but it seems to be doing the right thing
at the moment.
We also need to share this code between QCocoaWindow and QCocoaPanel.
Thanks to the dynamic nature of objective-C we have to have a copy of
the code in both places. It's unfortunate.
Finally, it's also important to have the QWidget let Cocoa know it has
focus after it has been created. So, make sure that is in sync.
Task-number: 249296
Reviewed-by: Prasanth Ullattil
|
| |
|
