We don't support native widgets in Android, so we can get into a mess
when people set this widget attribute, since the FB compositor
will assume that all widgets have their own backing store. This adds
a capability flag to the QPlatformIntegration which allows the plugin
to disable the WA_NativeWindow feature.
Task-number: QTBUG-32685
Change-Id: Ic200487da4a297f71ab594cf7c90d1e1d53bacd3
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Add parsing for the window geometry specification to
QGuiApplicationPrivate. Enable the argument under a different
name for the other platforms as well.
Task-number: QTBUG-27349
Change-Id: I973b2c69f5172f7d0bc983b8ba4b0d164649ef02
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Sometimes it is nice that hiding a widget does not affect the
layout. This patch makes that possible by allowing hidden
widgets to take up space.
Change-Id: Ifbc1cdee0e112950acc025919b98199ea9558db7
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Instead of storing the application type as a uint, we use the enum provided
by QCoreApplicationPrivate. The former resulted in a few cases of wrong
logic where the values got mixed up, such as always printing the QtCore
console warning, even for GUI applications.
The qt_eval_is_supported function has been refactored to return enums instead
of magic values, to make the logic easier to read.
The same goes for qt_eval_days_left, which now only concerns itself with
the number of days left. qt_eval_is_expired() has been added to use for
easy checking of expiration date.
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: Ia0e85b2103f790a7e02e0d6e567a477b3145fcb9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
In earlier patches we allowed the user to control the
tooltip duration. However the user still couldn't control
the wake delay and sleep delay.
This patch changes that and is the final patch in solving:
Task-number: QTBUG-1016
Change-Id: I5e2c719737634ad7f371ad03691744612472ae70
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
On desktop platforms, widgets have traditionally received
focus on mouse press. On touch platforms (iOS, Android) this
is different, there you need to delay setting the focus
until a touch release (probably to check if the press starts
a flick or tap'n'hold etc).
This patch will add a new style hint SetFocusOnRelease that
can be set by the plugin to control this behavior in Qt.
Change-Id: I2e4d714894e327822c855eb48a3b28e354726e95
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
This adds a property that specifies how long a tooltip is displayed.
This partly solves:
Task-number: QTBUG-1016
Change-Id: Ieea218bbcb869f6b48e72913d967e74fa792f2e2
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Unit test by Friedemann Kleint <Friedemann.Kleint@digia.com>
Task-number: QTBUG-31569
Change-Id: I526d33d4f88a41f6ac349098476bc45af6c841b0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
It is deprecated and clang is starting to warn about it.
Patch mostly generated by clang itself, with some careful grep
and sed for the platform-specific parts.
Change-Id: I8058e6db0f1b41b33a9e8f17a712739159982450
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QWidget::setWindowIcon() and similar call createTLExtra()
which creates a QWindow without setting the native attributes
on the parent, which can cause crashes when setParent_sys()
decides to delete the window.
Task-number: QTBUG-31672
Change-Id: I4c40ee12741be88b2281df90329ffb698d4009eb
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
It is nice to be able to control how long time a tooltip is shown.
This is the first part of solving:
Task-number: QTBUG-1016
Change-Id: I8e313df8a2acdc5ccc91d9c8ce956c30c76daf4b
Reviewed-by: David Faure (KDE) <faure@kde.org>
We need to make sure that we don't reset() the context when the
QGLWidget is being reparented, as that will lead to the QOpenGLContext
being destroyed and not recreated, leading to a crash in makeCurrent().
Also, don't destroy() the widget if it has not yet been created, as in
that case there's no ParentAboutToChange event sent.
Task-number: QTBUG-31016
Change-Id: I409fff94456802a80bd72b470a6fbaee87505baa
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
If the menu bar is subject to height for width (HFW) we should of
course respect that, but in addition we should ensure that the HFW is
within the minimum and maximum height. This also is consistent with how
QGridLayout calculates the effective minimum row height.
This fixes a regression because change 4780f94e391b5e881497c5228661dead
turned QTabWidget into a proper height-for-width citizen, and when
setting a QTabWidget as a menuwidget, the buggy codepath for HFW was
suddenly hit in menuBarHeightForWidth().
Task-number: QTBUG-31057
Change-Id: I3c1bb8063c92d6eda7e9433e44f08967d8e1c43e
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
The HTTPS links fail in Qt Assistant on Windows as the
qt installation package includes qt libraries that are
built without SSL support for legal reasons.
Task-number: QTBUG-31073
Change-Id: I86909abadb1e8164749d924cc53ee05aa57f8f31
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Karsten Heimrich <karsten.heimrich@digia.com>
Fix the inline editor of the QMenuBar in Qt Designer not working
due to the key events being sent to the QMenu which is open
at that time.
Task-number: QTBUG-31059
Change-Id: Ic96bc119d0d2566d8f8d6ee62858445a70a447b7
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
The comment to the code said it was to avoid double click.
However it actually breaks wanted double clicks.
The reason for it must be that the replayed event in earlier
code versions could be changed into a double click (together
with the first event).
However (now) we only test qt_replay_popup_mouse_event in
void QWidgetWindow::handleMouseEvent(QMouseEvent *event);
Regardless what kind of event we receive as input it will send
QEvent::MouseButtonPress when it sends replay mouse event.
I.e. it will then call QCoreApplication::sendSpontaneousEvent(r,e)
=> QCoreApplication::notifyInternal(receiver, event)
=> QCoreApplication::notify(receiver, event)
=> QApplicationPrivate::notify_helper(receiver, event) (+filters)
=> (probably) QWidgeWindow::event(receiver, event)
=> further handling in widget classes.
That especially means that it will *not* get into the function
QGuiApplicationPrivate::processMouseEvent where doubleclicks are
created. Therefore no doubleclick can be made from the extra event.
That makes the statement have no good effect - just side effects.
Change-Id: I190baff3c060548775201695e324059560bb7106
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
All occurrences of `#if defined(Q_OS_MAC) && !defined(Q_OS_IOS)` have
been replaced with `#if defined(Q_OS_MACX)`.
Change-Id: I5055d9bd1845136beb8ed1c79a8f0f2c0897751a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
moc currently silently ignores them, but I have a version which display
a warning.
Change-Id: I9a239cb7e99d40a57a013fb66357c4a6426d6e8b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
QWidgetWindow will always redirect mouse events to the active popup
(if any). The same logic is not implemented for touch events, which
means that touch events are always delivered to the widget under the
finger.
It is therefore possible to interact with widgets that are modally
shaddowed by the popup. It is also not possible to close popups
without touching them directly.
This patch will ignore touch events when a popup is active, and
as such, force a synthesised mouse event to be sent instead.
Implementing proper touch support also for popups is out of scope for
widgets.
Change-Id: I023c09c3e1fd4e5495df990c11419c69ecafb8f9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
The current documentation is not terribly clear on this topic, and there's a
couple of posts on various forums where people want to do this. In fact, the old
wording suggested (at least to me) that it is OK to explicitly override a
disabled state, which is apparently not true.
Change-Id: I10c54e0089e9ba5d16958aea62df27feafdf7b3d
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Similar to what change a298216bb4 does for update(QRect) we clip
the update region against the widget's rect and return if it's empty.
Otherwise we risk ending up with update rects that are larger than
INT_MAX due to multiple update rects being merged.
Task-number: QTBUG-30876
Change-Id: Idf695b1fdca50449a1e5ddf37500653de290590c
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
QApplicationPrivate::translateTouchToMouse always sets
buttons() to Qt::LeftButton for synthesised events. This is wrong
for a mouse release, since 'button' should in that case be
Qt::LeftButton, and 'buttons' should be Qt::NoButton (since no buttons
are actually being pressed).
This caused problems for QGraphicsView, which refuses to
release any mouse grab set on a QGraphicsItem if at least one
button is being pressed (which was always true).
This resulted in broken drag behavior on touch platforms.
Change-Id: Iefe63cd753f9f8bb04278fd04a4d728e3deda25e
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
We can simply clip the update rect against the widget's rect and return
if it's empty. Otherwise we risk ending up with update rects that are
larger than INT_MAX due to multiple update rects being merged.
Task-number: QTBUG-30876
Change-Id: I23bd0149fbe8d1a007a60b228e6bddb45dc4fc32
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
This change restores a proper function of the "(?)" button in the window
decorations which is used as a clue for the user to check what a particular
widget is supposed to do. The change is only implemented for QtWidgets because
the underlying QWhatsThis is inherently widget-specific -- which is why it sends
an event to QGuiApplication, but only processes it in the QtWidget-specific
QApplication.
Thanks to Alberto Mardegan and Gunnar Sletta for their feedback on this patch.
Change-Id: Ibb912e3960f1e9aec54c5ed77ade1c6744d6ca23
Reviewed-by: Alberto Mardegan <mardy@users.sourceforge.net>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Since change 3bb9024952 the documentation is invalid.
Task-number: QTBUG-29680
Change-Id: I7d5fcb6bc490aa5cba83439d33f798459640c42d
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
Previously if l had a parent, addChildLayout would warn and skip the
reparenting, but it would still add the sub layout to the layout.
This caused some inconsistencies in the hierarchy which in worst case
could cause crashes.
Task-number: QTBUG-30758
Change-Id: I618ec3341636b97bd71e421201b22c746dcf43e1
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
If the application object is an ancestor of QMenu, dereferencing qApp
in its destructor will cause a crash.
Task-number: QTBUG-30756
Change-Id: I31a33db0fd783bb210a420618911ea8b412e9a0f
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Setting this flag causes scroll event lag, so we want
to keep it off for all widgets that do not need touch
events. QPanGestureRecognizer is installed on all
QAbstractScrollAreas. Prevent it from setting the
flag.
Change-Id: Idd4fcc545ff26377607b56f75db75c2865a5fc82
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
Invoke slot "beep" on QPlatformNativeInterface. Implement for
Windows and X11.
Task-number: QTBUG-30416
Change-Id: I2be651165b899e5147818a012001d354827bb090
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Add QWindow::alert() and QPlatformWindow::setAlertState().
Add logic to clear alertion state when the window becomes
active. The platform plugins then only need to implement a setter
and a cheap getter and need not handle activation.
Prototypically implement X11 and Windows.
Task-number: QTBUG-30416
Change-Id: Ia70c4722d812462a21f4034b7d52735c9f2bc49c
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
While the raster platform plugin supports multiple top
level windows, this is not supported on the GL plugin,
so if you use GL or QtQuick2 in your app and use several
top levels, the app would crash with an error message.
A problem is that the top-level SurfaceView is a special
overlay View and does not support being stacked in a
layout. So instead, we let all windows share the same
GL surface and draw on top of each other. This works
fine for simple use cases.
We implement a new platform capability to make sure no
top level windows (even combobox popups and dialogs)
get non-fullscreen geometries. That has never
worked properly with the eglfs plugin.
Task-number: QTBUG-30473
Change-Id: Ia1438019638fc739cc93ffe79b46b81631254df2
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Previously QPainter computed the devicePixelRatio
based on the physical and logical dpi, and expected
that the ratio between them would be either 1x or
2x.
This was problematic for paint devices like printers
where the physical dpi can be much higher than the
logical dpi, and also for QScreen where the physical
dpi would have to be defined as a multiple of the
logical dpi.
Add QPaintDevice::PdmDevicePixelRatio and QPaintDevice::
devicePixelRatio() getter and implement it for the
QPaintDevice subclasses. Use it when calculating the
highdpi scale transform in qpainter.cpp and when scaling
the clip rect in qwidget.cpp.
Remove physical dpi scaling for QImage, QPixmap and
QOpenGLPaintDevice, reverting to the old behavior.
Change-Id: I6c97510613196d4536ff39d08e9750b8782283d4
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>