| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qapplication_x11.cpp
|
| |
| |
| |
| |
| |
| | |
Removed lots of places where we check for Tiger. Now we can assume it.
Reviewed-by: Morten Sørvig
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Ah! One less ###!
The scroll functions in Carbon and Cocoa don't scroll the regions that
have been marked dirty. In the past, we killed performance by updating
the whole view. We got a workaround for Carbon in the form of an SPI,
but I wasn't aware of a corresponding item in the NSView API, but it is
there publically and available in 10.5. Fast scrolling in Cocoa now for
people who like to use the keyboard.
Reviewed by: Morten Sørvig
|
|/ |
|
|\ |
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
|\ \
| |/
| |
| |
| |
| |
| |
| | |
Conflicts:
src/3rdparty/phonon/qt7/mediaobject.mm
src/3rdparty/phonon/qt7/quicktimevideoplayer.mm
src/gui/text/qfontengine_win.cpp
tools/linguist/shared/cpp.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
events."
This reverts commit 7314c07a3e443b1d5349b419a03db8d41ca43f7e.
As reported by Eike, this patch caused several problems for Qt Creator.
Potentially it may cause problems for other (external) applications as well.
An alternative fix (scheduled for 4.5.x) needs to be found for tasks
254456 and 254460.
Reviewed-by: Richard Moe Gustavsen
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The reason is that cocoa looses the first responder when
we raise the fake window inside the MDA area. So we need
to re-set the first responder again
Task-number: 255040
Reviewed-by: Trenton Schulz
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On Mac, a widget with a NoFocus policy could still get focus
(if only temporarily) as the result of a native focus event.
In particular, a line edit with a completer should
not lose focus (if only for a brief moment) as a result of the
completer popup being shown. This will for example cause an
item delegate to think that the user has navigated away from
the cell and delete the line edit as a result. This will in turn
cause the completer to access a null pointer.
Reviewed-by: Richard Moe Gustavsen
Task-number: 254456 and 254460
|
|\ \
| |/
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qobject.cpp
src/corelib/kernel/qobject_p.h
src/network/access/qhttpnetworkconnection.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Seems like we were not using the correct functions for setting
the max/min size on a cocoa window. The version we used before included
the unified toolbar, which is wrong. The new one does not.
Task-number: 252642
Reviewed-by: Trenton Schulz
|
|\ \
| |/
| |
| |
| | |
Conflicts:
tools/macdeployqt/shared/shared.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Seems like some old legacy code was left behind when sheets behaved as
application modal. This is not the case anymore, so this patch just
removes the special case code for enforcing the old behaviour, and let
carbon do the correct thing instead.
Task-number: 252379
Reviewed-by: Trenton Schulz
|
| |
| |
| |
| |
| |
| |
| |
| | |
Seems to work correctly in Cocoa, but we need to handle this special
case in Carbon ourselves.
Task-number: 253324
Reviewed-by: Richard Moe Gustavsen
|
| |
| |
| |
| |
| |
| |
| |
| | |
I actually found a few functions that were not even implemented, only
declared. Those should obviously not be in the header file. I've also
removed a few functions not in use / not belonging to QWidgetPrivate.
Reviewed-by: Olivier
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch cleans up several things, like bit fields that are
interleaved with with other variables, resulting in bits not being
packed properly.
Example: "uint a : 8; int c; uint b: 8;" -> "uint a : 8; uint b : 8; int c;"
In that case we'll use 12 bytes instead of 8 bytes.
I've also changed the order we declare certain variables to avoid
unnecessary gaps/padding on 64-bit architectures.
Example: "char *a; int c; char *b;" -> "char *a; char *b; int c;"
Pointers are 64-bit aligned, so padding appears between 'c' and 'b',
resulting in a total use of 24 bytes instead of 20 bytes.
...and since I anyways was moving the code around, I took the
opportunity to add some overall structure by first declaring
cross-platform functions/variables followed by platform specific
functions/variables. ...and it was kinda scary to actually be
able to see all the QStrings, pointers and whatnot we put into
QWidgetPrivate. I'm sure we can remove lots of stuff, but I'll do
that in a separate commit.
Quick numbers (X11/64 bit):
sizeof(QWidgetPrivate) == before: 472, after: 456
sizeof(QTLWExtra) == before: 112, after: 104
sizeof(QWExtra) == before: 152, after: 144
Acked-by: Olivier
|
|\ \
| |/
| |
| |
| |
| | |
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
|
|
|