If an embedded image is already encodeded as an png or jpg write the
data as is instead of decoding to a QImage and re-encoding as a new
image.
Change-Id: I479ae1fddbf59900a500497dd1bdf7449c21f273
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Replace QWindow / QScreen / QPlatformScreen overloads with template
functions that take a generic context argument.
The API now no longer supports implicit conversions from
QPointer<QWindow> to QWindow *, add explicit data()
call to usage in qxcbdrag.cpp.
Change-Id: I63d7f16f6356873280df58f4e7c924bf0b0eca5b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Fix the condition introduced by that determines whether
a completion is started on signal QFileSystemModel::directoryLoaded()
(introduced by 416ec00e7c859a844a5bcb24c7a31147aed974c / Qt 4).
Observe case sensitivity and the native separator and return true for
root directories.
Task-number: QTBUG-38014
Task-number: QTBUG-14292
Change-Id: Ie425c04d2df256248e84250ba777793a8106a738
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
getTextBeforeCursor() and getTextAfterCursor() were not properly
handling the case when the cursor is in the middle of preedit string
(just as TODO comments inside these functions were saying). This was
causing problems with Gboard when the user focuses a text editor by
tapping in the middle of a word.
Fixes: QTBUG-58063
Change-Id: I4a580a74d79965816557bfb342337975348d1c45
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
According to Android docs start == end in a call to setComposingRegion()
means finish composing. But this case was not being handled properly:
m_composingText was being assigned an empty string, but
m_composingTextStart was being assigned the value of start, which is
never -1.
There is one other possible cause of "Input method out of sync"
warnings, but it is tightly coupled with another bug, so it will be
fixed by a separate commit.
Change-Id: Ie475df84f330453ce4fc623e8b631b435d7d0042
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Send the aboutToShow() signal to QMenu before synchronising the
widgets for the menu items. This fixes a bug where if new
QWidgetActions are added to the menu from a slot triggered by the menu's
aboutToShow() signal, then such new actions do not shows up correctly on
Mac. Other platforms are not affected by the change.
Fixes: QTBUG-75826
Change-Id: Ic245d3fbc7ddde6944cca6cdb8e8951380c846ec
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: I6c1d83624838362f6a3daa6c2b309fb518a25d4b
Fixes: QTBUG-75673
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Reviewed-by: Johan Helsing <johan.helsing@qt.io>
This allows closing, minimizing and maximizing the window.
Fixes: QTBUG-74999
Change-Id: I8b3ad806a1767586c8cf7e5a1848fc0e525621cd
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
If the native color dialog is in use we haven't created any of the
widgets and will crash when trying to update them.
Change-Id: I6c43cc47359110c3b9db7cacb62581446cc6f7a3
Fixes: QTBUG-75858
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Qt on macOS has traditionally not included a BOM in the UTF-16 data,
but due to iOS requiring it it was changed in 4e196159. This had the
unfortunate side effect of breaking macOS applications that were not
prepared for the BOM, even if the public.utf16-plain-text UTI can have
an optional BOM, most notably Microsoft Excel. It also resulted in the
public.utf8-plain-text having a BOM, as that's automatically generated
by macOS based on the UTF-16 content we give it. Having a BOM in UTF-8
is technically fine, but not required, and recommended against.
The fact that iOS requires a BOM is a bit dubious, and most likely a
result of applications or system frameworks decoding the data using
NSUTF16StringEncoding, which assumes big-ending byte ordering if there
is no BOM, as opposed to public.utf16-plain-text which assumes native
byte ordering. Since we can't fix iOS our best bet is to include a BOM.
For macOS though, we revert back to the old behavior of not including
a BOM, since that seems to surprise macOS frameworks and applications
the least, even if having a BOM in public.utf16-plain-text should be
fully supported.
Longer term we should look at what kind of UTIs we generate. Most apps
on macOS do not generate public.utf16-plain-text, but instead generate
public.utf16-external-plain-text, which differs from the former in that
it assumes big-endian byte-ordering when there's no BOM. On iOS apps
seem to generate public.utf8-plain-text, and do not generate any UTF-16
UTIs. Moving Qt over to these UTIs would fix the problem as well, but
is a larger change that needs more research.
Change-Id: I4769c8b7d09daef7e3012e99cacc3237f7b0fc1a
Fixes: QTBUG-61562
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The window tends to grow to span screens in multi-screen setups; force it to
be on the primary screen by showing it maximized in that case.
Change-Id: I984ba7a4cd4abd1f862c59c8dca0e2275f44c724
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
- Use nullptr
- Use range-based for
- Use correct static invocation
- Set a title on shown windows to make it possible to identify
slow tests
- Fix the class declarations, use override, member initializations
- Use Qt 5 connection syntax where possible
- Ensure top level widget list is empty after each test, delete left-over
menu bars and disable menu animations
Change-Id: Ieeb943ea669cd139f1835088b816802e777a9676
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Introduce origin(QWindow *), which returns the point
around which coordinates should be scaled: the screen
origin for top-level windows, and (0, 0) for child windows.
The code paths for top-level and child windows can
then be combined.
Change-Id: I6b9cdbd9e7c2d9406e9137e325c4eb5c79e3ac9a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When the left or right mouse buttons are pressed over the window title
bar a WM_NCLBUTTONDOWN/WM_NCRBUTTONDOWN message is received. But when the
button is released, no corresponding UP message is received, but only
a WM_NCMOUSEMOVE or WM_MOUSEMOVE. This makes the internal mouse button
state stored in QGuiApplication get out of sync with the actual state,
resulting in an incorrect button state being used in QWheelEvent.
This patch detects the button release condition and generates the missing
release event.
Change-Id: I6dd9f8580bd6ba772522574f9a08298e49c43e61
Fixes: QTBUG-75678
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
When bringing an application back to foreground, args may contain NULL.
These nullptrs should not cause application crashes.
Fixes: QTBUG-75843
Change-Id: I642e3c359216e7706bcb13508399999a51a4fc2d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Document public macros in Qt5CoreMacros.cmake. This will replace
the list in the current CMake Manual.
Task-number: QTBUG-72159
Change-Id: I377412fe0c1d0a9b232162bbab88ac830d2cac80
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Use a fuzz check (cf 6309062722) and a minimum
size similar to tst_qwidget to make the test pass on large monitors with or
without active scaling.
Change-Id: I5a9e28e38e1d007057894c349c94f0e6fe12009c
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
- Use nullptr
- Fix C-style casts
- Fix redundant bool expressions
- Fix else after return
- Remove unnecessary casts to int from registered enums
- Fix most signedness-related warnings
- Use range-based for
- Use correct static invocation
- Set a title on shown windows to make it possible to identify
slow tests
- Fix the class declarations, use override, member initializations
- Use Qt 5 connection syntax
- Remove unused variables
- Streamline code in some cases
Change-Id: I1350b382b0b7d0f3198039fdc78892cfa1dd498d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
- Use nullptr
- Fix C-style casts
- Remove unnecessary casts to int from registered enums
- Fix most signedness-related warnings
- Use range-based for
- Use correct static invocation
- Set a title on shown windows to make it possible to identify
slow tests
- Fix the class declarations, use override, member initializations
- Streamline code in some cases
Change-Id: I4c9b99126cff02136def0e03accdf1129fe6d72b
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
- Use nullptr
- Fix C-style casts
- Use range-based for
- Use correct static invocation
- Set a title on shown windows to make it possible to identify
slow tests
- Fix the class declarations, use override, member initializations
- Use Qt 5 connection syntax; use lambdas where applicable
to remove helper slots
- Streamline code in some cases
- Replace helper function to convert touch points by the one in
QWindowSystemInterfacePrivate
- Use a logging category for the debug outpt, silencing some output
Change-Id: Ia46c7ad7c08f3afc8e5869ea99b66e406de97781
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
It's not clear why this test fails - and only does so sometimes - but
fail it does, so we ned to skip it to let development keep going. As
it happens, the same platform over-optimizes various computations
using qfloat16; which can at least be used to test for this platform,
since it wrongly distinguishes two qfloat16 values that theory and all
other platfomrs agree should coincide.
Fixes: QTBUG-75812
Change-Id: Ie9463d7dc21bca679337b475d13417b9f42bbf9b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Fusion style's SH_ItemView_ShowDecorationSelected hint is hard-coded to 1,
but in QCommonStyle::drawPrimitive (which QFusionStyle inherits) it only
asked its own QFusionStyle::styleHint() before drawing the background that
happens to be under the tree row decoration (arrow thingy or +/- symbol).
And the style doing the rendering does not know about QStyleSheetStyle so
by the time we get to QCommonStyle::drawPrimitive() it's too late to check.
Therefore QTreeView needs to avoid calling it in this case.
Fixes: QTBUG-73251
Change-Id: I2d0ed4d3b2ee805a5602122273387982caa564f8
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The code that deals with text selection in the iOS QPA
plugin, listen for changes to text selection. And depending
on whether we have a selection or not, we show or hide
the selection handles together with the edit menu.
The problem is that the edit menu will also be told to
show from other places, even if there is no selection. And
for those cases, we should avoid closing it.
This patch will check, before we close the edit menu, if we're
tracking a selection. If not, we leave the edit menu alone.
Fixes: QTBUG-75099
Change-Id: I001d818fa2ad4a215cc3fa6aa4c7faf516e1ed59
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When there is no DBus session, there will be no Linux accessibility,
since it relies on the presence of DBus.
Fixes: QTBUG-50189
Fixes: QTBUG-51940
Change-Id: I7503011b39ba2a806ddc12e89d0f7bd72a628b64
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
FT_GlyphSlot_Oblique(), the Freetype function to synthesize a
slanted/italic font, only accepts glyphs with outline format. So
disable loading bitmap format glyphs when that function will be used.
Fixes: QTBUG-73586
Change-Id: I762a4bc34537e0725ead0fb063d50c997403143d
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
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>
Since change c808a6978b plugins.qmltypes and designer/* didn't
get copied anymore for a non-prefixed build. Fix this, and clean up surrounding
code.
Fixes: QTBUG-75682
Change-Id: Ic6de94a5b01dae08929a67cbaedde60d120a4807
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Including both qopenglextensions.h and qopenglcontext.h would cause
ambiguity for the compiler when using QOpenGLContext
Change-Id: If8e46741c86d7639f442b5ac05a4493da784eb2f
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Having Aqua-themed controls in AquaDark theme looks interesting but not
very native. Clear cached Cocoa controls on theme change notification.
Change-Id: I884bf4434211be670aecc317935eb00b3fb6013c
Fixes: QTBUG-73652
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It's a recurring bug seen in user code and a warning will help
reduce it.
Warns only for the attributes that have such requirement in the docs,
but maybe we should be more strict and warn for any attribute.
Change-Id: I68148521953221ad0e8be1028181f52a7f22d2cc
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Atomic being supported and atomic being requested are two different things.
(the latter is only true when QT_QPA_EGLFS_KMS_ATOMIC is set)
Log accordingly since this can be very important to know when investigating
problems.
Change-Id: I6947d18e7c0eaef3fe160095cb046770f9c93efe
Reviewed-by: Johan Helsing <johan.helsing@qt.io>
scanLine is overflowing with big images. Similar change was made in
4f88475a96 to fix the same issue with
QImage::scanLine.
Fixes: QTBUG-75082
Change-Id: Ifedf28fa9a303c189dfcd12bd4ec11f438540c2e
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
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>
Postpone the screen change until the DPI changed event in case a move
between screens with different DPI is detected.
Task-number: QTBUG-65580
Change-Id: I356f144b243d7d1ce7feabf0434c3f534b903965
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
When introducing EnableNonClientDpiScaling() for QTBUG-53255, the window
frame calculation was not adapted. That is, window frames were calculated
from the style for the primary screen only, causing
- minimum size constraints not being calculated correctly for applications
on secondary screens when populating the MINMAXINFO structure.
- warnings about not being able to apply a geometry when moving fixed
size windows across screens.
The calculation of the frames for propagating size hints is also no longer
required after 3035400f36, which retrieves
them from the WM_NCCALCSIZE message; QWindowsWindow::fullFrameMargins() can
be used instead.
For newly created windows, use the newly added AdjustWindowRectExForDpi()
function to calculate the initial frame size.
Change QWindowsGeometryHint from a class to a collection of static functions
and add overloads to calculate the frame.
In checkForScreenChanged(), update the margins until WM_NCCALCSIZE is
received.
Task-number: QTBUG-67777
Task-number: QTBUG-65580
Task-number: QTBUG-53255
Change-Id: Iff2d382b2b316adec6c1a0622ae8015dba6de371
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Make these functions handle the case where a window spans multiple
screens, and high-DPI scaling is enabled, and the local position (in the
window) is not on the window primary screen (as returned by
QWindow::screen()).
This is done by detecting the case, and then calculating
the correct position using the native coordinate system.
[ChangeLog][QtGui] QWindow::mapToGlobal()/mapFromGlobal() now handle
windows spanning screens correctly.
Done-with: Friedemann Kleint<Friedemann.Kleint@qt.io>
Task-number: QTBUG-73231
Change-Id: I3c31b741344d9e85e4f5d9e60bae75acce2db741
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
There are some cases (model resets in weird positions) where we would
crash due to accessing invalid model indices.
Fixes: QTBUG-61416
Fixes: QTBUG-71608
Change-Id: Ibfedcbd921a3145f3e1596ac424a77f2319a5c46
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
...instead of compatibility, in order to play nice with systems
that have no compatibility profile support (macOS). Instancing
needs OpenGL 3.x so sticking with 2.x contexts is not an option.
The example looks fully compatible with core profile so its
functionality should not change.
Change-Id: If0d554a6208973aa8a4fb86757e246d170cd0e71
Fixes: QTBUG-75680
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We already reset it though e.g. QWidget::destroy, but if the backing
window is destroyed spontaneously or via another API we need to catch
that and send a WinIdChange event so clients who pulled out the original
winId will not think the pointer is still valid
Change-Id: I8556940ee871e81a51f73daeb2064f95bf41371c
Fixes: QTBUG-69289
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Try and explain better the situation around QSharedPointer:
it's reentrant, not thread safe.
Change-Id: Ief9d28be8ea3fbaa6014cb6b999626db1bab52ca
Reviewed-by: Martin Smith <martin.smith@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Combined width of all four buttons (cut, copy, paste, select all) is
greater than width of the screen in some locales and/or on some devices.
This was causing width of the last button to be set to zero and height
of the whole popup to grow too much due to word wrapping in the last
button. The context menu used to look something like this then:
Cut Copy Paste S
e
l
e
c
t
a
l
l
This commit disables word wrapping and enables text ellipsizing for
button labels. This fixes height of the popup. In the long term though
Qt will probably have to implement an overflow button like in Android's
built context menu.
The linked bug report contains before and after screenshots.
Fixes: QTBUG-72933
Change-Id: I8e270dbf8ca66f99748cdc531a77e11a5ab11c2b
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
The value of start for a QInputMethodEvent::Cursor attribute must be
specified relative to the start of preedit string, but longPress() was
specifying it relative to start of surrounding text. This was causing
QQuickTextInput to return wrong values of cursor and anchor rectangles.
And this was causing invalid positioning of cursor selection handles
after a long press.
Change-Id: Ief67e86dd90b09ebf2ba191a2b0311ff803afdd9
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
If an application enables FP exceptions our FP-based unpremul will
raise the INVALID exception. Since disabling them locally might be slow
just take a slow path when detected.
Fixes: QTBUG-75592
Change-Id: Ie22a032a4f62229f68ad21ede359c62291adc9bf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This was disabled in 9f22ac0aa0 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>
The bounding rect was computed based on the font metrics HarfBuzz gave
us, but those may not be 1:1 with what CoreText ends up using. When that
happens, drawInRect: will line-break the last word, which makes it fall
completely outside of the single line bounding rect. This is not a good
failure mode, so we prefer to draw the text at a point instead, allowing
the resulting text to draw slightly outside of the bounding rect. This
is preferable to adding a random padding to the width and hoping it will
be enough to solve the problem.
Change-Id: Ifa58a33bd9fad689ed4ee947327b7079f3c1b61d
Fixes: QTBUG-74565
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
