| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
To avoid duplicating code in ANGLE, we can resize the framebuffer in QPA.
This potentially allows us to synchronize rendering to avoid displaying
a frame which is rendered for the new geometry but is displayed with the
old geometry.
Change-Id: I5f3a0634628d9ea4ca73349a02e646eb043bd757
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When font embedding is explicitly disabled, fall back to painter paths
as we would if the font prohibits embedding. Note that this flag was
never respected on any platform in any version of Qt, as far as I've
been able to tell, because the handling of it in the X11 print
engine was removed shortly after it was introduced in 2005.
[ChangeLog][Printing] Disabling font embedding is now possible using
the QPrinter::setFontEmbedding() function.
Task-number: QTBUG-41943
Change-Id: Ice5e893f9893c5243310ae7892bec7497dd55c4a
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This passes the EGLConfig created in the platform screen to the
underlying context, and certain GPUs are blacklisted to be prevented
from creating a configuration which does not render properly with Qt
Quick.
Task-number: QTBUG-42260
Change-Id: I7e1cdc33c2f5662538723c6930fad5f13b151d6f
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
|
|
|
|
|
|
| |
Task-number: QTBUG-40621
Change-Id: Ibe069d4f93ac317e4f1b9ef5fc6bc3edcfac8685
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
Upstream changed how WARP is meant to interact with EGL, and so the
enum names changed.
Change-Id: I10d4bcac71b75a1223ea8af4d3fcf584f5685a02
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the menu is closed from the keyboard gesture, and
the focus object doesn't change, the menu will still
be in a visible state, even if the keyboard is hidden.
This patch will ensure that this can not be the case
by listening for keyboardWillHideNotification. Since
we have no guarantee for when the destructor runs, we
apply a pessimistic approach and ensure we stop listen
when the menu gets closed.
Task-number: QTBUG-42523
Change-Id: If734ea32d1823b978c9c1c67ebcc5b6c3c5c338c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
| |
Since the picker menu uses IM to set an alternative
input view, we also need to specify that we IM is enabled.
Task-number: QTBUG-42523
Change-Id: Ia559fbc0ca7e6a1a4499d5eb179baa2d915ecb17
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current approach of reloading input views assumes that
the first responder is not a QIOSTextResponder, but
a QUIView. This is not always the case, e.g if someone
calls update after setting IM enabled on current focus
object to false. In that case we'll try to close the
keyboard by reloading input views on a quitextresponder which
can fail if the text responder has an external input view
attached.
This patch will instead hide the keyboard by resigning first
responder when it is a QIOSTextResponder. If it is not
a QIOSTextResponder it means that the keyboard is already
closed, or a third-party UIVIew that supports key input is first
responder. In either case we then leave it as-is.
Task-number: QTBUG-42523
Change-Id: I4dab648af9029941a8d5d3b00011fbd169be5482
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
| |
Change-Id: Idd37942842dc59ae391b6b34308d4c01e7a25bc5
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Without setting firstResponder to 0 upon destruction, the current retain
count would never reach zero after the event was used. The result being
that QIOSTextResponder was seldom destroyed, which would also affect its
inputView etc which would also be kept alive.
Change-Id: Ia88e6a9d8764e7e9532487153e5e81a7ad0f9741
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
We'd transfer or clear first-responder in a lot more cases than just
when transferring to a new Qt window, such as when presenting a new
view-controller on top to send an e-mail or take a picture using the
camera.
Change-Id: I6b2a8a6d9fd99910b96a86cf9847b7ff0128f20a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|\
| |
| |
| | |
Change-Id: I85e3dfa62f217b76447276dd7cce6b9eac3a144e
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Calling the function has the same effect as dismissing the keyboard using
the native keyboard dismiss button or the hide-keyboard gesture, and will
result in the QIOSTextInputResponder losing first-responder status and
the current focus object being cleared.
QtWidgets and other parts of Qt will try to hide the keyboard during
focus changes between widgets, which we already take care of when the
focus object changes, so we detect the situation and ignore it, by
requiring that the current focus object matches the one we've brought
up the text responder for.
Showing the virtual keyboard is still a no-op, as there is no way to
show the virtual keyboard without a focus-object.
Change-Id: Iefcb403c2b6d3da8a4df3fcd53bc1244ba9c4d23
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Allows us to track state through the normal gesture recognizer states
instead of custom variables.
Change-Id: I4fe1b370a581132a9bbb8f51f7bee73381b80341
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-42427
Change-Id: Ie35d5e0f72be3a16ecb6b928e12bc50d9f183590
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The defaultConfiguration could switch and be either active connection,
so we determine the default should be what has the default route.
Change-Id: I194f27b60e7a3598eca2ff09c2225ba1a46564d9
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Cabling changes can be detected right away, so we should act on that
and change the configuration state.
Change-Id: Ifa9709077215567001e11ab655208a2c1b090073
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
|
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-42368
Change-Id: I306733b5de7871fdeaa0accb512a3610753c84a5
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
IBus can hand us multiple attributes for different formatting properties
of the same text range for events. The IBus input method plugin used to
convert these straight into multiple QInputMethodEvent::Attributes, each
with their own QTextCharFormat instance.
According to the QInputMethodEvent documentation, behavior with multiple
TextFormat attributes for the same text range is undefined. In at least
one known user, KDE's Kate text editor, it causes invisible text for
pre-edit text events as the QTextCharFormats are applied in turn with
partially default-constructed foreground/background brushes:
https://bugs.kde.org/show_bug.cgi?id=339467
This patch makes an effort to merge formatting information for identical
text ranges into a single QTextCharFomat, while otherwise preserving
existing behavior (attribute order is unchanged and attributes deseria-
lized from D-Bus as having invalid QTextFormats remain untouched).
No attempt is made to cope with overlapping text ranges. Segmenting into
smaller ranges and merging for the overlaps would be conceivable, but
until a case of an input method creating events with overlapping ranges
is known seems not worth the effort.
It's worth noting that the IBus input method plugin for Qt 4 also
attempts to merge formatting information into a single QTextCharFormat,
but with a distinct implementation from this one.
Change-Id: Ie3dc38b353724ffb7b5f2d7f316393027373baf2
Task-number: 41640
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Not all platforms do have QRegularExpression as it is based on
pcre.
Change-Id: I6b8e701ff7cf30e776ee34e5dc836cd24c9543b5
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The GraphicsView stack still seems to have issues emitting focusObject
change signals when the focus object changes inside the item hierarchy.
To be on the safe side we use our own view of whether or not IM is
enabled, and try to detect and warn if we find a case where the two
are out of sync.
Change-Id: I9fde896ea14ea5b65784723110887e06453edbd4
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Found by clang static analyzer.
Change-Id: I8f15ae1a8e6afb91eafa6cee1d1b21e3539af6c1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Refactor old code
Stop memory leaks
Properly support mobile data (ofono)
Change-Id: I7f23882ee0ee345a049a4a93ddd452b6d2e53710
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Any filter not filtering on suffix shows up duplicated in filter
combo.
Change-Id: I9fc9e33b6081cf6894fabc6dd52c12a4d3dfd393
Task-number: QTBUG-42405
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Needed so that we can build simulator builds for x86_64 as well as
i386. The function call alignment is the same, but we need to use
the 64-bit versions of the instruction and operands.
Change-Id: I62cc78e23b5e0923382d19570ce18f558894e6a0
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
| |
| |
| |
| | |
Change-Id: Ic768790a90ef7048bd5e7027e9682988085368fe
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
...instead of using the current mouse position. This
is important if event processing is delayed: we want
the QMouseEvent to have the position when the event
happened, not the current position.
Regression from Qt 4.
Change-Id: Ifd4f0f02853236a204de96c5a97e72f86c29f0b7
Task-id: QTBUG-37926
Reviewed-by: Timur Pocheptsov <Timur.Pocheptsov@digia.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Will be fixed in a different way.
This reverts commit ae5f3df59b37e0ce8aaef27dc1e02f40def340ae.
Change-Id: Ie706396667a5b6c9003bb92a018d88346a180e65
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix "Recursive repaint" crash.
Add guard to QCococaWindow::setGeometry and QNSView
updateGeometry to prevent processing window system
events during setGeometry.
Task-number: QTBUG-41449
Change-Id: I304fdf134d433cbc50fafd997ecd91e31cb57f4e
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conditions for when updateExposedGeometry() should
actually send the expose event goes into the function
itself.
The window()->isVisible() check could arguably be
moved to isWindowExposable(), but I'm keeping this
as a straight refactor without any behavior changes.
(isWindowExposable() is called from multiple locations)
Change-Id: I6d792286ccbc50065ebfc588daca2240761a1937
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Qt expects a handleWindowActivated call for non-
popup windows only. Add a window type check, similar
to the other handleWindowActivated calls.
Task-number: QTBUG-38707
Change-Id: Iaa5959675f7e3ae4664bdf785d3f374debb0d0a7
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
Reviewed-by: Liang Qi <liang.qi@theqtcompany.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In rare cases, the Windows event loop can be spinning inside the inner
loop and the message hook is never called. This can be triggered on the
Direct2D platform by opening 32+ window handles.
The issue can be worked around by using the same approach Windows CE uses:
don't rely on the message hook to inform the event loop that the post
message has been delivered. Instead, uninstall the hook and let it be
called directly by the event loop.
Task-number: QTBUG-42428
Change-Id: I10280126dd50729bc260aa5f7029549e2e061c01
Reviewed-by: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
The private was not deleted. Adding the dtor in turn
causes a warning about not having a virtual dtor
in the base class, so add that as well.
Change-Id: I24a90caf2cf6192a6f17cf5af96b8f77010d9127
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
|
| |
This key combination should open the context menu.
Task-number: QTBUG-40085
Change-Id: I7cfc89f766b3734b9fb9d3c9135b4896ffbadb5b
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
The result of pressing the key is still a Qt::Key_Return press/release
sequence, which needs to be handled manually.
Change-Id: I72c7b0067bd3ec1bc315ab2c84361800b7be0943
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Marius Bugge Monsen <marius@cutehacks.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The technique of sending an action does not always end up at the actual
first responder, but it will end up in a responder in the responder
chain of the first responder, so we continue searching the subviews
recursively until we find the real first-responder.
Change-Id: I6abc9bc18eb127fa4b317cd308783c0ecfcd670a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
| |
Instead of faking it, by returning YES for isFirstResponder, which caused
issues when iOS would try to dismiss the keyboard by resigning the true
first-responder.
Change-Id: I816c4cf9c699d72995ce7968e1f1a4aa9c9c167e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The JNI environment should be managed by QJNIEnvironmentPrivate
directly or through QJNIObjectPrivate. There is also a clear
difference between calls coming from or going into Java code.
Calls coming from Java already comes with the 'right' environment and
in most cases no extra considerations or set-up is needed.
Change-Id: I92d935ddfb70332041869185d5a92438930ff9b9
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
This is one of several fixes where the goal is to simplify the jni code
by letting QJNI manage the environment.
Change-Id: Ia714e25fbb3fcd170150392e822b0a3fc3812818
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
Let the QJNI classes manager the jni environment and caching of jni
handles.
Change-Id: I8c238375026adf449d6e6e2b521caa6cd63a0fb4
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
Add platform backend for QWinRTWindow::setWindowTitle.
Task-number: QTBUG-40736
Change-Id: I0b03c9b5977368b38ba63044b00178c3f2bb0b86
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gtk library usually takes care of this when the main
Gtk loop ends, but since Gtk's main even loop is not
used in QGtk2Dialog we have to store clipboard's content
with help of gtk_clipboard_store(). This function
sends a SAVE_TARGETS request to X11 clipboard manager
to save clipboards contents as required by ICCCM.
Task-number: QTBUG-34475
Change-Id: If784c425ea4a36ec1c3a8ddc0cdec080f57681a5
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
|
|
|
|
|
| |
Q_ASSERT expands to nothing in release => mode unused.
Change-Id: Ieb9ec4382e925250e1146239ce061763003ff6ba
Reviewed-by: BogDan Vatra <bogdan@kde.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was observed in the weather app, where sometimes we could not find
an items window. This could only be observed in the search results of
the cities. (while VKB was visible).
The old code traversed up to the QQuickListView and then it could not
traversed further up in the parent hierarchy. Because of this it
could also not find the associated window handle.
The reason for this is unknown, but maybe it could be related to the
fact that QQuickListView is a Component.
Regardless of this, invalidate the cache should invalidate everything.
We also traverse through all top level windows, but on iOS there should
not be too many top level windows...
Change-Id: I56a496435bb529a53d5ece8446cd2eeff502af84
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
|
|
|
|
|
|
|
| |
Also fixes a compiler warning with clang
Change-Id: I99beb7e099477b2b8b53af0e9fd32a7605a6c08a
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
|
|
|
|
|
|
| |
Change-Id: If4d9c9c769b598a3194a7cd5bbe5c74e7650694b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Previously, the device was delay-created, which is a problem
if its type is to be used for determinining the pan gesture type.
Task-number: QTBUG-40461
Change-Id: I2dee3d7a3786a0fdf0a9b2b9e174dd121697ab44
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|
|
|
|
|
|
|
| |
The patch 916dfcb8275bcce6b39606cd0b930239a60dc5df while fixing one problem,
introduced another - leaking CGImage.
Change-Id: I08db6ea9fa97ae3489a0bfa1f93e0d18f3671885
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
|
|
|
|
|
|
|
| |
Some CFStringRefs created with CFStringCreate* methods were not being
released. Using the QCFString helper class to perform auto release.
Change-Id: I36d15c0d35118524089e99ea3cd53c41342d6308
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
|
|
|
|
|
|
|
| |
CFRelease should be called IFF PMPrinterCopyDescriptionURL succeeds
Change-Id: Id289aea3a4e3da397dae4062319256a043538597
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
|