| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
We were already using the 'native' nomenclature when referring to these
kinds of APIs, e.g. when talking about native handles, or the existing
QPlatformNativeInterface on a QPA level. Using 'native' for the user
facing APIs also distinguishes them from the 'platform' backend layer
in QPA and elsewhere.
Change-Id: I0f3273265904f0f19c0b6d62471f8820d3c3232e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the porting from Qt 4 to Qt 5 an assumption was made in QKeyMapper
that the underlying platform implementation needed the native scan
code to be able to resolve the possible keymaps for an event.
As a result, the macOS platform plugin started sending key events
with a fake native scan code of 1, so that it would still be allowed
to map key events.
Which in turn led to the documentation of QKeyEvent::nativeScanCode()
getting an exception for macOS.
Let's clean up this by removing the original assumption, and leave it
up to the platforms to decide what information from the key event
is needed.
QKeyMapperPrivate::possibleKeys() will still call extractKeyFromEvent
as a fallback if the platform layer doesn't return any possible keys.
Change-Id: I122a45bcec658c45ccc0b2c0671eb264d85d7be6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
The [NSEvent charactersByApplyingModifiers:] API only supports key
down events, but we might get into QCocoaKeyMapper::keyMapForKey for
modifier key presses as well (even if QShortcutMap::nextState tries
to filter out modifier keys).
Change-Id: I02f163edac2baa9052f34b4d5d31b6a627d3d85c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
|
| |
This image is already a combined image of all urls that we drag.
Pick-to: 5.15
Change-Id: I8fe45f64a6022881320d100f8a6f4a25fcac73b9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fix is not final yet, it's just to plumb the serious bug/regression
of accessing NSPasteBoard in some strange state and the one we have not
populated yet/do not even own (?). Drag image(s) is broken atm and will
be fixed in the follow-up patch.
Pick-to: 5.15
Task-number: QTBUG-71939
Change-Id: I5c3ac3ec138d7407c2e0c206485478aa5244ae15
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to somewhat inverted logic introduced by the 8481a9fc974a1f1dd44a,
testing number of items in a pasteboard happens _before_ we fill it,
which is wrong and useless. As a result, maybeDragMultipleItems will
prevent the single item drag.
Pick-to: 5.15
Task-number: QTCREATORBUG-24665
Task-number: QTBUG-86786
Change-Id: Ia4be9fc56677575bb363cbb8b1adbea59e6c3b0b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not use QVariant::Type anymore, instead use QMetaType
For some reason, this pushed the qvariant autotest over the limit where
MSVC requires the /bigobj flag, so add that one.
[ChangeLog][QtCore][QMimeData] The signature of the virtual retrieveData()
function has changed and now takes a QMetaType instead of a QVariant::Type.
Change-Id: Ib46773bd731ee2177b1ef74d8162d744be7017ef
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
| |
Resolve remaining Qt6 TODO
[ChangeLog][QtCore][QAbstractEventDispatcher] The signature of the abstract virtual registerTime function now takes a qint64 value for the interval parameter.
Change-Id: I10166ad5cfb455edc404d465a3731ff094a8977e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation for [NSWindow performWindowDragWithEvent:] only
mentions mouse-down events, but starting a drag from move and drag
events works too, so include them as well.
Pick-to: 5.15
Fixes: QTBUG-85105
Change-Id: Ib6c29ed4035bfccc61d50a7f95f564fb3d56fcf6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
| |
Allows more flexibility in the future.
Change-Id: Idcf2d8ddaee268a7b5d55379ccb42dd9b3c33abf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we have a platform plugin we ask the platform to quit, and if
not we fall back to the base implementation of QCoreApplication
that sends Quit events directly.
This allows the platform to involve the rest of the system in the
process. The platform will then come back with a spontaneous quit
via QWSI::handleApplicationTermination(), which will then send
the corresponding Quit even from QGuiApplication like normal.
Task-number: QTBUG-45262
Task-number: QTBUG-33235
Task-number: QTBUG-72013
Task-number: QTBUG-59782
Change-Id: I0000aaf7192e4b905933c5da0e53901c6c88f26a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix our API, so that QStringList and QList<QString> are the
same thing.
This required a bit of refactoring in QList and moving the
indexOf(), lastIndexOf() and contains() method into
QListSpecialMethods. In addition, we need to ensure that
the QStringList(const QString&) constructor is still available
for compatibility with Qt 5.
Once those two are done, all methods in QStringList can be moved
into QListSpecialMethods<QString>.
Change-Id: Ib8afbf5b6d9df4d0d47051252233506f62335fa3
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
| |
This change shouldn't matter much to widgets, since style names
there are case insensitive. But for controls style names are
case sensitive, and in that case, "macOS" looks more correct.
Change-Id: Ia1d442bce465692ff58fecba1cc68ecbb2e52549
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not forwarding the native virtual key code when sending key events
in the flagsChanged handler caused a number of problems, e.g. the
inability to determine which of the Alt or Shift keys were pressed.
Use handleExtendedKeyEvent to include the native virtual key code.
Patch inspired by Nyan Pasu.
Fixes: QTBUG-69608
Change-Id: I15e9ff1069528d4b50ee4638ab2d8a6fd279db0b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The optimization resulted in losing out on window focus changes when
for example a native file dialog was shown, resulting in the cursor
blinking both in the parent window, and in the native file dialog.
Pick-to: 5.15
Pick-to: 5.12
Change-Id: I9c1f9df20fbc5c4b80f906ded70d9a2658b70438
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
| |
They are unused.
Change-Id: I77383f2be45551401ed9c2f88285511134cc8b0d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
| |
Change-Id: If5d7c5e037b99c14c51d83adf8b1e20d6b924bc5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
| |
It will become illegal; keep the semantics but force the
right casts.
Change-Id: I4002c5bca6eb90e798e35ca263e7bbb4ff5ad4b1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upgrade existing functions to be virtual functions:
- virtual QString iconName()
- virtual bool isNull()
- virtual QPixmap scaledPixmap(...)
- virtual QList<QSize> availableSizes(...)
Make all of them non-const and remove the const_casts in
the implementation. Keep the default implementation
which calls virtual_hook(), for compatibility.
Note: availableSizes was already virtual, but now loses
the “const”. Port two overrides in the platform themes.
Keep virutal_hook() around for future expansion.
Task-number: QTBUG-85885
Change-Id: I76d0c9f75bfd6ca870c669047d4ef18b82c692e5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the name/key of the style to 'macos'. Besides the
name 'macintosh' being archaic, we also need this
change to avoid creating 'macintosh' style folders
in QtQuickControls, now that we plan to use QPlatformTheme
also there to resolve the style.
[ChangeLog][Widgets][QStyle] The 'macintosh' style
has been renamed to 'macos'.
Change-Id: I14b8a8b4dbd369e7a7d16b94e4ad27e501e7e8d0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
| |
Change-Id: I2e31d43492f94edf4030fdbd88c1000396bdf250
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having three methods with the same name doing different things is
unnecessarily confusing, so follow the standard naming convention in
Qt and call the getter of the resolve mask resolveMask, and the setter
setResolveMask. These methods were all documented as internal.
The publicly documented resolve() method that merges two fonts and
palettes based on the respective masks remains as it is, even though
'merge' would perhaps be a better name.
Change-Id: If90b1ad800834baccd1dbc38fc6b861540d6df6e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
| |
Change-Id: Id0a8ac5cc516732e6bc03c4a7d153486003d0881
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
MidButton had its // ### Qt 5: remove me
upgraded to Qt 6 at 5.0; but it dates back to 4.7.0
Replace the many remaining uses of MidButton with MiddleButton in the
process.
Pick-to: 5.15
Change-Id: Idc1b1b1816673dfdb344d703d101febc823a76ff
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
| |
Export some private functions from QUtf8 to resolve
undefined symbols in Qt5Compat after moving QStringRef.
Task-number: QTBUG-84437
Change-Id: I9046dcb14ed520d8868a511d79da6e721e26f72b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Use the QPlatformDialogHelper standard buttons to get the translated
button text as then this will already have been translated for those
loading a translation.
Pick-to: 5.15 5.12
Fixes: QTBUG-85725
Change-Id: Ia42d93aeb6e1b5c0528564a6c960a35f6710c8eb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our deployment target is 10.14, which enables layer-backing by default,
and our layer-backing support nowadays is stable enough that we don't
need to maintain any of the old code paths for compatibility.
The wantsBestResolutionOpenGLSurface property on NSView is only relevant
for surface-backed views, so we no longer need to deal with it.
Change-Id: I8aef4ac99371113d463ac35eee648a8a2fd1ea72
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We observe changes to the NSWindow to pick up color space changes,
so we need to track when the platform window is destroyed and created
to match our observer with the recreated NSWindow.
This does not handle the fact that we're internally recreating the
NSWindow if certain window flag changes requires so, without letting
clients know via surface events.
Task-number: QTBUG-85915
Pick-to: 5.15
Change-Id: I7a7d728c742def79adebaadc985cedd86ea0d581
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The observer we add for the NSWindow of the backingstore window
will not be valid once that window is destroyed, but we may get
last minute notifications for it still, in which case our platform
window is gone.
This patch fixes the immediate crash, but reveals a more fundamental
problem of assuming the platform window that's alive during construction
is the one that will always be used with the backingstore. This is not
the case when for example QtWidgets opens a combo box, and reuses the
backingstore for the widget each time the combobox popup is shown.
Fixes: QTBUG-85915
Pick-to: 5.15
Pick-to: 5.12
Change-Id: Ia66a45d003882602ac29476aabf2d58b0ac33c1e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QFontDatabase is a singleton and all instances would share
a single, mutex-protected global data pointer. But some functions
were implemented as non-static functions. This caused a lot
of code on the form
QFontDatabase().families(...)
since there was no static access. Other functions were implemented
as static.
To consolidate, we make all functions static. This should be
source-compatible, but not binary compatible.
[ChangeLog][QtGui][Fonts] Some functions in QFontDatabase were in
principle static, but previously not implemented as such. All
member functions have now been made static, so that constructing
objects of QFontDatabase is no longer necessary to access certain
functionality.
Fixes: QTBUG-83284
Change-Id: Ifd8c15016281c71f631b53387402c942cd9c43f6
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Discard the color space and return the selected RGB/CMYK
color components, without any color space conversion.
This enables predictable color handling as long as you
stay on a single display. All color triplets are display
RGB: drawing the QColor returned by getColor() will
reproduce the selected color on-screen.
(Predictable color across multiple displays require
color management, which is out of scope here).
Fixes: QTBUG-84124
Pick-to: 5.15
Change-Id: I43d8dc15d07635fabdd0662c84f7c0b5ac40b7ab
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-84220
Change-Id: I951e04bfe9358a99951d1d61ff47b675584b7f81
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
|
|
|
|
|
|
|
|
| |
Pick-to: 5.15
Pick-to: 5.12
Change-Id: Ide57f675b20b08210f301da5177df45d008423c4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
| |
Change-Id: Ie4a53bbc16cde7b4aa68172015bbfeaa9e316bcc
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
|
| |
This is no longer a problem, and this condition should be
handled by QCocoaGLContext in any case.
Change-Id: Iaac9d1a8962b27bf6f0394b8c1ea3e46dc28e29e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QPlatformWindow initializes its view of the geometry based on the
QWindow geometry during construction. If the initial geometry we
then compute is the same, we would end up exiting early from
QCocoaWindow::setGeometry(), because we compared the new geometry
against the QPlatformWindow::geometry(), and the geometry would
never be reflected in the NSView.
Due to other setGeometry calls this was in most cases masked, but
could in theory happen, and is preventing us from cleaning up other
parts of the code.
The call to QWindow::setGeometry() after setting the initial geometry
is also broken, as the initial geometry is available through the
platform window and QWindow::geometry() already, so setting it again
serves nothing except disabling d->positionAutomatic, which is not
correct.
Change-Id: I0db3cfe7d7c3d14070beee6ae3ea3dfd49da9e05
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit a2bdda8e3ba added an unconditional hide of child NSViews,
which was found to be too strict, and worked around in a199a87ad
by undoing the hide during setParent(). The unconditional hide
was then changed in 89842b97d7 to use the visibility state of
the window, which means the workaround in a199a87ad is no longer
needed.
Change-Id: If0df2de65693e03c5fb53a906b1399accab3fcc4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
A QWindow should only become Active when it's inside an
NSWindow that is Key. If the NSWindow is not key, we need
to wait for it to be so, and handle window activation
from QCocoaWindow::windowDidBecomeKey() instead. Otherwise
Qt will report a QWindow as Active when, in reality, it
is not.
Change-Id: Ib7e63b374f26af527a668c7f7d863c4168a4446d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
| |
They should not clutter the "public" QPA headers that clients
use to implement new platforms, and having them in the private
headers allows us to check for private configure features.
Change-Id: Ib4b4db96c086d81bb5810392c7c8922fc5b4950d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
|
|
|
|
|
| |
For now we just verify that the Cocoa API produces the same keymaps
as we get from Carbon. Once that's verified we can solidify the code.
Change-Id: I0d2aa1bb0a006d29c0149e3ff2fd5299ba922326
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
| |
Change-Id: I3e8a4cfa611b6ae575466c493aac438dc831e89a
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some goals that have hopefully been achieved are:
- make QPointerEvent and QEventPoint resemble their Qt Quick
counterparts to such an extent that we can remove those wrappers
and go back to delivering the original events in Qt Quick
- make QEventPoint much smaller than QTouchEvent::TouchPoint, with no pimpl
- remove most public setters
- reduce the usage of complex constructors that take many arguments
- don't repeat ourselves: move accessors and storage upwards
rather than having redundant ones in subclasses
- standardize the set of accessors in QPointerEvent
- maintain source compatibility as much as possible: do not require
modifying event-handling code in any QWidget subclass
To avoid public setters we now introduce a few QMutable* subclasses.
This is a bit like the Builder pattern except that it doesn't involve
constructing a separate disposable object: the main event type can be
cast to the mutable type at any time to enable modifications, iff the
code is linked with gui-private. Therefore event classes can have
less-"complete" constructors, because internal Qt code can use setters
the same way it could use the ones in QTouchEvent before; and the event
classes don't need many friends. Even some read-accessors can be kept
private unless we are sure we want to expose them.
Task-number: QTBUG-46266
Fixes: QTBUG-72173
Change-Id: I740e4e40165b7bc41223d38b200bbc2b403e07b6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
The plumbing from QKeyMapper to the platform specific key mappers
via QPA was never done, so this method is unused. The code path
in QKeyMapper that would trigger it would be changeKeyboard(),
but that's already handled in QCocoaKeyMapper, and wouldn't be
initiated from the cross platform code in any case.
Change-Id: Ibc0c419627fc0430d028945038c1f2fbafe42d4b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
| |
Change-Id: Ie2e2c6e1b1daf08146fd42f3ce58194ee1918794
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
| |
Change-Id: I080bfaec273ea45809d72e513add16b7114c7bbb
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
| |
Change-Id: Iae33f627ad6abfc9bbba9b098417bd13caee00f8
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
| |
Change-Id: I489c64733275260bb041f8df5cc5ff4a571d4e9c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qt::UNICODE_ACCEL had no effect since at least Qt 4.0. We can drop
it in Qt 6. The whole Qt::Modifier enumeration is still widely
used, so we can't drop it yet, but we should aim at doing so in
Qt 7. Add a note.
[ChangeLog][QtCore][Qt::Modifier] The Qt::UNICODE_ACCEL enumerator
has been removed. It had no effect since Qt 4.0.
[ChangeLog][QtCore][Qt::Modifier] Usage of the enumerators in
the Qt::Modifier enumeration is discouraged. The enumeration
will likely get removed in the next major version of Qt.
Change-Id: If25f30d920878d32903b91a38044f5da042c7eab
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
| |
It's not yet clear how to get any more specific information about it,
or how to detect multiple keyboards.
Task-number: QTBUG-46412
Change-Id: Ib7d6e00e1f6f120b3b8c71cb5d74a8411d61dc00
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|