Due to popular demand. It does have it benefits (especially when
it comes to convenience) to allow grabbing QOpenGLWidgets even
when they are not part of an actual window and are not actually
visible.
Does not involve much more than dropping the warnings and bailouts
when there is active native window (because the QOpenGLWidget/its
parents are still hidden).
In addition the device pixel ratio from metric() has to be fixed
as well.
[ChangeLog][Qt Widgets] QOpenGLWidget is now able to render and
return its content via grabFramebuffer(), QWidget::grab() or
QWidget::render() even when the widget has not been made visible.
Task-number: QTBUG-47185
Task-number: QTBUG-61280
Change-Id: Icc2b0b3ce9778a3eb6409d54744238568abb0f0d
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
It's the subdir where the implementation also lives. There's no
src/widgets/gestures, either.
Change the mac: into a darwin: scope in the .pro file, so Sanity Bot
does not complain.
Change-Id: I7608d6da05af4a1117db585798a87a20ae80717a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Add additional code paths to map the index passed by QCompleter in its
activated() signal in case when QCompleter's model isn't the same as
QComboBox's one.
Task-number: QTBUG-52027
Change-Id: I1d74037fccbe19962bb7f242aa7b1c2441aa5d54
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
In the referenced bug report, dismissing a QFileDialog while the
Qt Virtual Keyboard was in use would result in a crash.
Dismissing a file dialog created with
e.g. QFileDialog::getOpenFileName() causes it to eventually be
destroyed. When this happens, it starts deleting its children. Each
child widget's destructor calls clearFocus(). In clearFocus(), there is
a block of code that emits QWindow::focusChanged(), passing the result
of focusObject() called on that widget's window.
QWidgetWindow::focusObject() could end up using itself as a fallback
focus object if it had no other focus objects (e.g. children) to use
instead, even though it was in the process of being destroyed; as were
all of its children. The Qt Virtual Keyboard plugin would then try to
use the focus object, even though it was in an invalid state.
To fix this problem, we return early from QWidgetWindow::focusObject()
if the window is in the process of being destroyed.
Task-number: QTBUG-57193
Change-Id: I137cf9415812ce2e0419c0afe8076ce150f248cb
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This makes the test a lot faster and perhaps more reliable.
Change-Id: I055cfde627c75f71735eabbf01af2a196bd8b00a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
It was grabbing a QLabel without accounting for the size of
the window in the case where the DPI is larger than 1:
FAIL! : tst_QWidget::translucentWidget() Compared values are not the same
Actual (actual.size()) : QSize(32x32)
Expected (expected.size()): QSize(16x16)
Change-Id: I4873f3c6364ee2696f5612d91e6c97c60b2cd915
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This is a followup to 77a8e90cdd which
didn't handle the case where no columns had been moved.
visualIndices and logicalIndices are empty until initializeIndexMapping()
is called, in which case appending is wrong.
As a result, visualIndex(i) would return -1 for the values over
those added by read(), and an assert would happen at painting time.
The fix is to leave visualIndices and logicalIndices empty if
they are empty already, leaving it to initializeIndexMapping()
to fill them later if necessary (e.g. when moving a column).
Task-number: QTBUG-60837
Change-Id: Ia7e4b9d3122647984acd434dfaa0400df319d065
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
When the mouse is moved over a header section then if there is a status
tip then this should be sent as an event like it would for a typical
QAbstractItemView.
Also adds a test for the StatusTipRole for the QTreeView itself as well as
the header.
Task-number: QTBUG-2066
Change-Id: Iaef8d91f1bd621c2463cde2dff4b2291fb037975
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
No need to have two enums for the exact same purpose.
qmacstyle auto-test updated as well.
Change-Id: Ia601648191e39c0cbbaa7477143441005ae063c2
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Known to fail now and then, most likely due to the mouse cursor
moving while the test is executing.
Task-number: QTBUG-60754
Change-Id: Id8f0786416d0df33f197a7a8f99b7aad1341a6be
Reviewed-by: Liang Qi <liang.qi@qt.io>
QWidget has its own setVisible() code that needs to
be run in order to correctly transition widget visibility.
It is desirable to be able to show and hide (native)
widgets also from the QWindow side, for example from
the platform plugin, or from generic QWindow handling
code in QtGui.
Add a new virtual QWindowPrivate::setVisible() and
move the QWindow visibility implementation there.
Subclasses can now override this function to add custom
code.
Make QWidgetPrivate::show/hide_sys() call the QWindowPrivate
setVisible implementation instead of the QWindow setVisible
public API.
Change-Id: I082f174b100659e1221d5898b490f8a9f498abdf
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
CI metrics show that this test was flaky ~38 time in 3 days.
The problem is old: after we get a surface, a window manager can still
decide to re-position the window.
The fix is to simply send the touch event in a position where it is sure
to hit the window (usually the offset is the title bar height).
The blacklisting seems to not have worked, I could reproduce the failure
on a linux/xcb machine.
Change-Id: I5229fe020ba75c984fd3b6c322ad00d769707573
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Change the check for the unambiguous match to be case insensitive.
Task-number: QTBUG-60466
Change-Id: Iaa019cc803a56b015f45309fb1b3a7a8a3d82ee4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The reference images in tst_qframe had to be updated to match the palette.
[ChangeLog][QtWidgets][QFusionStyle] The default palette used by the
platform agnostic Fusion style has been desaturated. Previously the window
background color, and other colors derived from it, were brown shades. Now
these colors are neutral gray that fit better on any desktop.
Change-Id: Id6a05e05563b8cbc8f378ee415a64b8f99012b60
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Unselecting with offscreen and minimal platforms behave similarly as in
Windows and QNX. If left or right key is used for unselecting, cursor
position is changed.
Change-Id: I022cd2fec80ad1875fec983e1e3536a105e18bb2
Reviewed-by: Teemu Holappa <teemu.holappa@qt.io>
Some features are not implemented by "offscreen" platform. Skip tests
failing because of that. Some failing cases are also already skipped or
blacklisted on "xcb" platform.
Change-Id: I17269169379c270bd7d6f2ddda03ad9b114a71ce
Reviewed-by: Teemu Holappa <teemu.holappa@qt.io>
Commit 288bfb0bbd added a test that uses QLineEditIconButton, which
requires QT_BUILD_INTERNAL to be defined in order for the findChild()
call to work as expected.
Change-Id: Ieda18f4e26a91322e8a83c14f8d1fbbe4313ecf0
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
QLineEditIconButton currently draws a fully transparent pixmap in its
paintEvent() function, when the line edit is empty. This does not work
when there is another trailing QAction that is visible even when the
line edit has no text, as reported in QTBUG-59957.
To fix this issue, make sure the clear button is always the leftmost
button.
Task-number: QTBUG-59957
Change-Id: I8a4f96aae07856aa0e1053ebb338ba9bdf052a16
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Preserve the device pixel ratio in the various helper functions
and when drawing.
Task-number: QTBUG-60026
Change-Id: Ieac9360b00044b6aedd0d3e1ad6e3b16d436f20f
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
If the mouse cursor is over a menu entry with a submenu, and the
submenu is open, quickly moving the mouse to a near menu entry and
clicking it sometimes results in the click being eaten: this happens
when the mouse is pressed before the submenu disappears and released
after it disappeared: the submenu resets d->mouseDown that is a static,
causing the mouse release event on the action we want to have no effect.
Set d->mouseDown to 0 only when the window is hiding is the actual
window that contains the mouseDown, otherwise is still valid.
Change-Id: I2c981b9432728e9e7518c30a146c9595199f8afe
Reviewed-by: Błażej Szczygieł <spaz16@wp.pl>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This enforces decoupling and in the case of QMacStyle, isolates
QtWidgets and therefore end user applications, from Carbon/HITheme.
Windows and Fusion are platform independent, so they remain built-in
(but mostly because the Windows style is tightly coupled to other styles
like QStylesheetStyle).
Task-number: QTBUG-59428
Change-Id: Id6519fe0c5269c1bce5b5921f9db06257032a1c9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
When tearing off either a non-scrollable multi-colume menu
or a scrollable menu, displaying the torn-off menu crashes.
The root cause is when the torn-off menu is created, the
tear-off menu's style, margins and other attributes are not
set to it. The patch is to ensure the torn-off menu has
the same attributes as the tear-off menu does and set the
torn-off menu with a correct menu size.
Task-number: QTBUG-24815
Change-Id: Icea45f149ea8792671af4a62e62cad6ee01a1f95
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Currently the contents margins and the menu paddings are not considered
for calculating the menu size, the positions and the size of tear-off
bar, scrollers and the positions of the menu items when scrolling the
menu, which results in the following problems when valid contents
margins and/or menu paddings are set:
- The tear off area is displayed in a wrong position. The mouse events
are not handled correctly in the tear off area. For example, when you
click in the tear off area, the menu should be torn off but nothing
happens
- For a multi-column menu, the menu width is not calculated correctly
- For a scrollable menu,
- the menu width is not calculated correctly
- the menu items are not displayed in correct positions
- the scrollers are not displayed in correct positions
- menu items are displayed on the area of borders and margins when
scrolling the menu
- the last menu item is not displayed above the bottom of the content
area when scrolling the menu to the end.
The changes are to fix the problems above.
Change-Id: I7931e1088dff0029f2d4825e2aa34b4e32fdccd9
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Later, the Windows XP style will be removed entirely by means of
being merged with the Windows Vista style (which inherits from the
XP style).
There was actually no reason for these styles being separate
classes in the first place, because both result in the same
appearance for controls on the running version of Windows.
Therefore, the windowsxp style merely appears as a "broken"
version of the windowsvista style, with only minor differences
based on the additional metrics that the vista style provides.
The windowsxp style does NOT, and never did, allow users to get
a Windows XP style appearance on Windows 7 and above (which is
currently Qt's minimum supported platform). Therefore, now that
Qt no longer supports Windows XP, the windowsxp style is unusable.
[ChangeLog][QtWidgets] The windowsxp style is no longer available
as a separate style, because it did not (and cannot) actually
provide an XP-style appearance on currently supported Qt platforms.
Change-Id: I513d9bce3f247f97cfb28dfee88fe888469e0a6f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
QTBUG-43818 does not affect only Android, it can be reproduced also
with qemu.
Change-Id: I6364c09b3c7f860b34899e26056ad562b7c338f2
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
QOpenGLWidget is not supported on all platforms. Skip tests on those.
Change-Id: I0f9500553427903f20d248acaa20803276e3ab00
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
tst_QWidget::updateWhileMinimized has been failing on Ubuntu 14.04
and was already blacklisted there. Now we extend it to cover Ubuntu
16.04.
Task-number: QTBUG-46116
Change-Id: I6758657cca46bb4c76cddb0298f9b87b8a43655b
Reviewed-by: Liang Qi <liang.qi@qt.io>
GCC bug 68949 causes tst_QGraphicsGridLayout and tst_QGraphicsLinearLayout
to fail on 5.2.x/5.3.x: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68949.
This change adds aggregate initialization to QSizeF arrays to work around
the bug. The bug was discovered when compiling and running tests on ARM
with GCC 5.3.0.
Change-Id: I9ecf7b032b6ca1477c29dca3bd7d0ec8d69a0454
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Fix the condition in QWidgetPrivate::resolveLocale() to decide whether
to propagate locale: make it match setLocale_helper()'s condition when
deciding whether to propagate to descendants. This lead to a
QDateTimeEdit's calendar popup not getting told what locale to use
correctly, unless we setLocale() on it overtly, which then blocked
propagation of locale changes to it unless QDateTimeEdit manually
propagated the changes.
Fix the documentation of WA_WindowPropagation to mention locale as
also being propagated (which it was in several places, only neglecting
this one in resolveLocale).
[ChangeLog][QWidget][Qt::WA_WindowPropagation] Propagate locale
consistently, along with font and palette, within the widget
hierarchy. Previously, locale was propagated on ancestral
setLocale(), but not on creation of the descendant.
Task-number: QTBUG-59106
Change-Id: I92270f7789c8eda66a458274a658c84c7b0df754
Reviewed-by: David Faure <david.faure@kdab.com>
