| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/global/qlogging.cpp
src/gui/painting/qtextureglyphcache_p.h
src/gui/text/qfontengine.cpp
src/widgets/widgets/qlineedit.cpp
Change-Id: Ic8798538df466b7141caa8bbf1fb7605eb56be37
|
| |\
| | |
| | |
| | | |
Change-Id: I5d2a4fa33b4aa22da39ac045e6b85ab940b8720b
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A switch statement was comparing enum values of a different enum.
Change-Id: I578f79b15b1007afaa64cd3a2a80d6a75d3bed77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The icon provided was ignored, even though NSUserNotification provides
the option to specify a contentImage.
The message popping up will show that image on the right side of the
notification; it will not repace the application icon on the left side.
[ChangeLog][Widgets][QSystemTrayIcon] On macOS, show the icon passed
into showMessage in the notification popup
Change-Id: I8ecda7f893006e74a4f35f37ddc07063ebfe4e83
Fixes: QTBUG-76916
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/network/ssl/qsslsocket_openssl.cpp
src/platformsupport/vkconvenience/qvkconvenience.cpp
Change-Id: I97ce6ed185f7fdad8102cc58d3cfec0119fd7bb4
|
| |\|
| | |
| | |
| | | |
Change-Id: I912bd8851c390302414d3dfb3c8220df5a0d5630
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes the usability issue of a modal dialog showing up behind a
splash screen, not visible to the user, but blocking user input and the
application startup sequence until discarded.
[ChangeLog][QtWidgets][QSlashScreen] On macOS, lower the splash screen
when a modal dialog is shown to make sure the user sees the dialog.
Change-Id: Ibae768f76909d930cb25dcf5cee31edc5f15c29a
Fixes: QTBUG-49576
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/io/qstorageinfo_unix.cpp
src/network/ssl/qsslsocket_openssl.cpp
Change-Id: Ibc9ce799bef62d60d616beaa9fbde8ebeadfbc20
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
.qmake.conf
src/gui/painting/qdrawhelper.cpp
src/network/ssl/qsslsocket_openssl.cpp
src/widgets/styles/qstylesheetstyle.cpp
Change-Id: Ibe1cd40f46a823c9e5edbe0a3cd16be1e1686b17
|
|\ \ \ \
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
.qmake.conf
src/gui/painting/qdrawhelper.cpp
src/gui/text/qdistancefield.cpp
src/gui/text/qdistancefield_p.h
src/network/ssl/qsslsocket_openssl.cpp
src/plugins/platforms/android/qandroidinputcontext.cpp
src/widgets/styles/qstylesheetstyle.cpp
Done-With: Timur Pocheptsov <timur.pocheptsov@qt.io>
Change-Id: Ia7daad21f077ea889898f17734ec46303e71fe6b
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
... in case the submenu is set from a slot, attached to the aboutToShow()
signal. Normally, with a 'statically' pre-populated menu, we set 'submenu'
property on a menu item from 'updateItem' callback in our menu delegate.
After that, AppKit calls our delegate's willOpen call back and this is
where we emit 'aboutToShow'. Unfortunately, if an application tries to
create a nested menu 'dynamically' at this point, it never becomes 'submenu'
of the item, since 'updateItem' was already handled at this point.
We catch this case in QCocoaMenuItem and call setAttachedItem if needed.
Fixes: QTBUG-76060
Change-Id: I676bf1d8529b9ddbfc90e4dff422b39668b7a5fa
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
m_requestedSize is already scaled by the QtGui scale
factor (e.g. as set by QT_SCALE_FACTOR). Multiplying
by QWindow::devicePixelRatio() then applies this factor
again.
Use QPlatformWindow::devicePixelRatio() instead, which
returns the platform scale factor.
Change-Id: I133e99d84f4718215fda9ef0cf81a113b51db2c7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The window shadow rendered by AppKit is based on the shape/content of the
NSWindow surface. If the backingstore is partially transparent, we need
to invalidate the window shadow after each resize (and subsequent flush)
of the backingstore.
Change-Id: I451370af5a8c0c25faea26beb3faa2483a33a5cf
Fixes: QTBUG-74560
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
User input events will be queued if processEvents()
is called with the ExcludeUserInputEvents flag. User
code then expect that the queued events will be sent
when the corresponding exec() call returns.
We were sending queued user input event at the beginning
of processEvents(). However, the cocoa event dispatcher
also has a mode where it makes a blocking call to
[NSApp run], in which case processEvents() never returns
during event processing. This means we don’t get to call
the queued-event-sending code.
Factor out the queued-event-sending code to a new
sendQueuedUserInputEvents() function. Call it from
postedEventsSourceCallback() to make sure the queue
is emptied after the ExcludeUserInputEvents processEvents()
call is done.
Task-number: QTBUG-69687
Change-Id: I4ff554ef4d39a69356736c33a650886b56bfdb4c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
qmake/generators/makefile.cpp
qmake/generators/unix/unixmake2.cpp
src/corelib/thread/qthread_unix.cpp
tests/auto/corelib/tools/qsharedpointer/tst_qsharedpointer.cpp
Change-Id: I1df0d4ba20685de7f9300bf07458c13376493408
|
| |\|
| | |
| | |
| | | |
Change-Id: Ic7c790602e4ac3f4a0d3d4630441b28cf76f75fc
|
| | |
| | |
| | |
| | |
| | |
| | | |
Change-Id: I2d21c883628933543ae5a66b694ff7503119bc4a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
qmake/generators/makefile.cpp
src/plugins/platforms/cocoa/qcocoaintegration.h
src/plugins/platforms/cocoa/qcocoaintegration.mm
Done-With: Jörg Bornemann <joerg.bornemann@qt.io>
Change-Id: I5a61e161784cc6f947abe370aab8f2971a9cbe78
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
cocoaButton2QtButton(NSEvent *event) did not handle NSEventTypeLeftMouseDragged,
NSEventTypeRightMouseDragged, NSEventTypeOtherMouseDragged.
Task-number: QTBUG-74763
Change-Id: I9f48230599f16400b49edbff392f712eb1fff782
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This also fixes a bug where we were implicitly capturing this inside
the block, which meant that we would crash if the theme was recreated.
The capture is now tied to the lifetime of QCocoaTheme.
Change-Id: I37df8e6c0b33bf41e76d66be3cf29576041a7546
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use m_buttons instead of currentlyPressedMouseButtons. The latter returns
the state of devices combined with synthesized events at the moment,
independent of which events have been delivered via the event stream,
so this method is not suitable for tracking.
Task-number: QTBUG-74057
Task-number: QTBUG-74121
Change-Id: Iabf99ada6c3d25a995c9ddf895059b70833a9051
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Reports say some systems get "Failed to find vkCreateMacOSSurfaceMVK"
even though MoltenVK and the corresponding extensionare there. While not
reproducable on single GPU Intel systems, it could be that not enabling
the extension on the Vulkan instance is causing this. Not opting in to
the extension is incorrect in theory anyway. So fix it in cocoa as well,
similarly to how other platform plugins do this already.
Task-number: QTBUG-76117
Change-Id: I75220f3582a700ce0037003086123d3d38524648
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Mike Krus <mike.krus@kdab.com>
|
| | |
| | |
| | |
| | |
| | |
| | | |
Change-Id: I1d8280fe88871572a3a27e612de49717b3b9ef77
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|\| |
| | |
| | |
| | | |
Change-Id: Ia279fc4a8226626041c772902a07b2f90f37b53b
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Due to PasteboardCopyItemFlavorData converting newlines to '\r' for some
UTIs we have traditionally had to shortcut these UTIs via NSStringPboardType
instead of the mime converters such as QMacPasteboardMimeUnicodeText.
Let's explain this a bit better for future generations.
Note that public.utf8-plain-text doesn't seem to have this problem
anymore, but it's left in for now to not cause any regressions due
to behavior change.
Change-Id: I7dce80828865c6323ed308780b8ca07b7a3e7c17
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The logic seems to be to prefer public.utf16-plain-text over the UTI
reported by the mime converter's flavorFor, but this doesn't make sense
for two reasons:
1. If the converter reports a UTI from flavorFor, we should respect
that as the preferred UTI. QMacPasteboardMimeUnicodeText already
reports public.utf16-plain-text as expected.
2. We don't know if the converter supports the public.utf16-plain-text
UTI, which is the case for QMacPasteboardMimeTraditionalMacPlainText
for example. The result is that we fail to retrieve any data. The
reason we haven't been seeing this issue is that the code path above
using qt_mac_get_pasteboardString will in most cases succeed and
return early.
Change-Id: I0b7e0d09a97389a229e7a945f17fef74ad5c2fc0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |\|
| | |
| | |
| | | |
Change-Id: I1bdc28a3ae825ea35e83f20fe16d2409515e5a3d
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Change c2c3452ba introduced a new API in Qt to let QPA inform
whether or not shortcuts should be shown in context menus. This
was set to false by default, since by observation, this seemed to
be the most common behavior across platforms. The problem
is that it left no way for the application to override it; The
attribute Qt::AA_DontShowShortcutsInContextMenus simply doesn't work
when shortcuts are always off. And for some application, showing
shortcuts is not just a matter of look-and-feel, but also important
information to be able to use the application the way intended.
This patch reverts the behavior back to how it was in Qt-5.9, where
shortcuts where shown by default (except on macOS where we still keep
them off). It's no so much because the "always off" logic is wrong, but
because there is no (easy) way/work-around for an app developer to switch
them back on (until Qt-5.13, where a new API is introduced to fix the
situation: b1a9a77). And this lack of API can be a show-stopper for some
when upgrading from e.g 5.9 LTS to 5.12 LTS.
This downside of this patch, OTOH, is that it can cause more
change that what is normally wanted in a patch release. But out of
two evils, this is the best option. Those that wan't to hide shortcuts
can set AA_DontShowShortcutsInContextMenus to true, which now will
work.
[ChangeLog][QtWidgets][QMenu] Shortcuts are again shown by default
in context menus, except on macOS. They can be forced off by
setting AA_DontShowShortcutsInContextMenus to true.
Fixes: QTBUG-69452
Change-Id: Ibcc371395944ac5b19b1d20889940da271bf73d5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The accessibilityAttributeValue method was deprecated and all needed
replacements are in macOS 10.12.
The new API is nicer, since it adds a lot of individual functions instead of
forcing one big switch statement on us. This makes it easier to implement
further protocols. When implementing e.g. the Button protocol, the old attribute
functions do not get called any more, so this is needed before implementing more
features.
Change-Id: I5a705edfa3f6bb0d25436df8cf5dd7f59e7e764e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We had an implementation of this based on the old attribute
based API, which also works. This cleans it up and adds
the setter.
Change-Id: I886fc9c89ee08b9f4f9aabec00ac1a5b9a800c6f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Modern macOS accessibility is based on protocols.
By implementing NSAccessibilityElement we get warnings
for missing functions for the most basic accessibility
functionality.
Change-Id: I0595ea5b9927c5bfb4bbeff3fc9322cb1f232b9f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/global/qfloat16.cpp
src/corelib/global/qfloat16.h
src/plugins/platforms/windows/qwindowswindow.cpp
Change-Id: I0938aaa6a9771f55e48c95ed29f6f5291431b947
|
| |\|
| | |
| | |
| | | |
Change-Id: Id3d16035c9692af42e9c1bf512218f3c836ae2eb
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
AppKit will in some cases ask our view to display on secondary threads if
we call APIs that are only supposed to be called on the main thread, such
as -[NSOpenGLContext setView:] or -[NSOpenGLContext update].
Forwarding this display-request is bad, as QtGui expects all window system
events to come on the main thread, and we can easily deadlock client code
such as the Qt Quick threaded renderer.
Change-Id: I1daeabf1dca6ca8ba908d3998b444a2089681e3a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| |\ \
| | | |
| | | |
| | | | |
refs/staging/5.13
|
| | |\|
| | | |
| | | |
| | | | |
Change-Id: I0c00ffe0eabebc919f22d6faa4bf958b288e8fd9
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This was disabled in 9f22ac0aa0254f20f9b26aec7b124d74141fdfcd under the
assumption that the windowDidResize callback was sufficient, but in the
situation when macOS native tabs are enabled, AppKit will report the
wrong geometry for the first windowDidResize callback when a new tab
is created.
We could potentially remove the geometry change in windowDidResize,
as the viewDidChangeFrame callback should be enough for content
views, but this is something that needs more investigation.
Change-Id: I85045507da1a01b4a906e6f88301f3321c660943
Fixes: QTBUG-75482
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It's not part of the QBackingStore API, but clients such as the Qt Quick
software renderer access it through the platform backingstore, to grab
the window.
Change-Id: I203484ce13a5f8fb6815d27ab07f874fa9d16b8c
Fixes: QTBUG-75467
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Using NSScreen as the basis for tracking screens is not recommended, as
the list of screens can be added, removed, or dynamically reconfigured at
any time, and the NSScreen instance, or index in the NSScreen.screens array
may not be stable.
Quartz Display Services on the other hand tracks displays via a unique
display ID, which typically remains constant until the machine is restarted.
The lower level API also gives us earlier callbacks about screen changes
than the corresponding NSApplicationDidChangeScreenParametersNotification
does. By reacting to screen changes _before_ AppKit does, we can remove
workarounds for receiving window move and screen change notifications
before the screen was actually visibly reconfigured.
The new approach also handles changes to the primary screen, which
can happen if the user moves the menu bar in the macOS display
arrangement pane.
The device pixel ratio of the screen has been made into a cached
property, like all the other properties of QCocoaScreen. This is
more consistent, and allows us to qDebug the screen even when it
has been removed and we no longer have access to resolve the
properties from the associated Quarts display.
Change-Id: I2d86c7629ed3bf5fb8c77f174712633752ae4079
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/tools/qstring.cpp
Change-Id: I81dbf90fc936c9bf08197baefa071117bddb1c63
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/tools/qlocale_data_p.h
(Regenerated by running the scripts in util/local_database/)
src/gui/opengl/qopengltextureuploader.cpp
Done-With: Edward Welbourne <edward.welbourne@qt.io>
Done-With: Allan Sandfeld Jensen <allan.jensen@qt.io>
Change-Id: I12df7f066ed0a25eb109f61c4b8d8dea63b683e2
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We can't rely on the previous screen and current screen to accurately
reflect whether or not the window has been moved from one screen to
another, or if the window just stayed on the same screen but the screen
was reconfigured by macOS. The reasons for this are many-fold, but
include factors such as Qt using the screen of the top level window
to resolve the screen of the child windows, and AppKit delivering
screen change events in an order that makes things harder to track.
The result is that we need to always send screen change events, for
all windows, including child windows, and we also need to restart the
display link by re-requesting an update request if needed, so that
child windows that are running animations will continue to animate
on the new screen.
Change-Id: I0b87849c41323e92c08f5115842be067fa8f8490
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Calling super will push the default arrow cursor, so we should only
do that if our own cursor has been unset.
Change-Id: I71d8934e7eab2b15e150730e2282e7063ada305a
Fixes: QTBUG-75552
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes: QTBUG-75612
Change-Id: I0e90a84697c1eb055c4150f2519829977fce7244
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
window.contentView can be of any NSView subclass.
Get to the QCocoaWindow via QCocoaNSWindow instead.
Change-Id: I8c761fd22e6078b075d8dd035ad767b9e4cb6da2
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Change-Id: Id95c096700a8bfa733d8620064c2a37eb19cc3db
Fixes: QTBUG-72741
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/kernel/qobject.cpp
src/corelib/kernel/qvariant.h
src/corelib/tools/qlist.h
Done-With: Milian Wolff <milian.wolff@kdab.com>
Done-With: Allan Sandfeld Jensen <allan.jensen@qt.io>
Change-Id: I6803f7239aa137a51a7467fab7cc7a01302a848d
|
| |\|
| | |
| | |
| | | |
Change-Id: Iaad9509712c848ed42ada2c25065162a6fc5a930
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Qt starts drag-and-drop on a mouse button press event. Cococa in
this case won't send the matching release event, so we have to
synthesize it here.
Task-number: QTBUG-72417
Change-Id: I645b6a2733c1ea11ac4545cf3405f826af45fa47
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: Ic1975db497613e3efe50be4246c167efe10d8e31
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|