qWarning now depends on QT_MESSAGE_PATTERN, depending on that variable.
It will show things like the moc process id or the Parser::error
function name. We don't want that.
Change-Id: I5b35401200f0f7de2442aa77d700a82402081489
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
The current implementation kept a list of TouchPoints that
was reused when sending active touces to QPA. This list was
never cleaned up, so if you pressed three fingers, and released
one, we would still continue to sendt three touches to QPA.
Especially, since this list was not cleaned up when receiving
a touch cancel, mouse events sometimes stopped working when trigging
a system gesture (like a four finger swipe). This can be seen by
using the fingerpaint example.
Since we cannot rely on TouchPoints having IDs that corresponds to
their index in the touch point list, it ends up being
simpler (and results in less code) to rewrite the implementation to use
a hash table of UITouch to TouchPoints instead.
Change-Id: I5b32f57a8d72a0b8759a64ac7cdfa6700109d2b3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.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>
The underlying rename() of the operating system simply does
nothing when renaming 'foo' to 'Foo' in a case insensitive file
system. Work around by moving in 2 steps.
Change-Id: Ibc73724bfca402a5ce7fcf2a83e8fea32ff71093
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: David Faure (KDE) <faure@kde.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It makes more sense to keep this workaround header together with the other
libxkbcommon files for a better access point since it's used by several *.pro
files.
Change-Id: I63d4eb58f6e7f3852834e41c4b6e058a2c962233
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
To have a properly working key input in the xcb plugin in the case when
xcb-xkb library is not available we can update the xkb_state struct with the
keyboard state information available in the X11 core events.
The current modifier state is reported to clients in a number of core
protocol events and can be determined using the QueryPointer request.
This is how it is done in Weston, Wayland's reference implementation.
Note: In case the X server doesn't have a xkb support on it (which is very
unlikely), then xkbcommon will only pick up the user's primary layout.
The X server with the xkb support stuffs unused bits (13 and 14) of 'state' in the
core events with the effective keyboard group, which we can use to determine layout
changes.
Change-Id: I9f1ef635109870e7412ef1157ca592f3c8f9271c
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
This is required for a modifier+key shortcut support.
Also fixes old Qt bug when keymap group changes were not handled
properly for shortcut functionality.
Task-number: QTBUG-26902
Task-number: QTBUG-4845
Change-Id: I04d2c2ad7049df7420999816154605848fa670e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
libxkbcommon is a keymap compiler [1] which utilizes xkb
keyboard configuration database [2].
xkbcommon simplifies keyboard state handling by providing xkb_state
object which holds the current state of all modifiers, groups, LEDs,
etc, relating to the provided keymap.
Detecting modifier mapping should become simpler once it gets supported
in libxkbcommon. Also with xinput2 we could get rid of the XkbStateNotify
events, because xinput2 key press/release already include all the mod/group
info.
[1] http://xkbcommon.org/
[2] http://www.freedesktop.org/wiki/Software/XKeyboardConfig
This patch:
- Removes a dependency to -lxcb-keysyms
- Removes a dependency to XLib call - XLookupString
- Enables required functionality to fix QTBUG-27681
Task-number: QTBUG-27680
Change-Id: I10e10f873821ee02f6df72238e215a541150f38f
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
1) -qt-xcb
a) Use xkb from the 3rd party libs. As it is done for the other xcb
dependencies when qt configure with -qt-xcb.
2) -system-xcb (default)
a) If xkb found then use xkb from the system. (Currenly xkb is not
enabled by default when configuring libxcb library).
b) If xkb can't be found on the system then keyboard state will be
updated from X11 core events.
Change-Id: I7c3dbce6daa2cec52067cd5af80f19040233a0db
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
This library is required by the XCB platform plugin. As we depend on
very recent version of this library and it might not be available
in base repositories of distributions, users can use -qt-xkbcommom
switch to build Qt with the bundled version.
Change-Id: I0ed2a5cc2f1df98b0e7cc926cabfa69818674e08
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>
Set up for downloading from the qt-project.org servers instead
of KDE servers.
Change-Id: I6f9e69f91ea956165300d75109e1683d0b1aa5f0
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Reviewed-by: BogDan Vatra <bogdan@kde.org>
We have to use the 4.4.3 compiler toolchain for producing binaries
for ARMv5 on Android, since the 4.7 toolchain has a regression for
this architecture. The regression has been fixed, but the fix has
not been released yet, so until it has, we need to use the 4.4.3.
However, the 4.4.3 toolchain has a different bug, which breaks
compilation in qtimageformats with a message about redefinition of
uint. This works around that bug for Android builds. When the
patched compiler has been released, we can revert this.
Task-number: QTBUG-30921
Change-Id: I620c186c6e932413a4de1dd331fbf4b9401f2e72
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Change-Id: Ida382a80dba882bbeb920756adc0c16321efe37e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Change-Id: I98145fb3149dd8f7aba60d305da98c148aa9c705
Reviewed-by: Volker Krause <volker.krause@kdab.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Fix C4267 MSVC warning.
Make sepSize an int, because this function is never called with a size_t.
Change-Id: I2b834fe7c1408e34d55d9f137231e2f5816f3f1d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The compiler defines _WIN32 for x86 builds.
The compiler defines _WIN32 and _WIN64 for x86_64 builds.
For consistency, the same should happen to the user defined macros
without underscore. The WIN32 macro is added in the win32-* mkspecs.
Task-number: QTBUG-30223
Change-Id: I342afed731f4ba253a2708b98f575039a04613d7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
/RTCsu and /RTCus must be handled as full runtime check options.
Task-number: QTBUG-30711
Change-Id: I783bf49f2ab1d4fd9636dca8e434bccb54844c8c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The vcxproj format supports the /we compiler switch as
TreatSpecificWarningsAsErrors tag.
Support for this switch got lost during refactoring of the
vc(x)proj generators for Qt 4.8.0.
Task-number: QTBUG-29098
Change-Id: I607e907dcb9c1bc7d261053b6d757941ec7db822
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
If a process dies before all output is read into the internal buffer
of QProcess, we might lose data. Therefore we must drain the output
pipes like we already do in the synchronous wait functions.
Task-number: QTBUG-30843
Change-Id: I8bbc5265275c9ebd33218ba600267ae87d93ed61
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
If \wrapper appears in a \class comment or a
\qmltype comment, qdoc will not print warnings
when it finds public members of the class or the
QML type that are not documented.
The \wrapper command is added to several
opengl classes. This reduces the number of
qdoc warnings by several thousands.
Task-number: QTBUG-30755
Change-Id: Iba1eebc1590ccf54100e40fe91423240c1b3d09d
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
Reviewed-by: Venugopal Shivashankar <venugopal.shivashankar@digia.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
in QDBUSXML2CPP_INTERFACE_HEADER_FLAGS and QDBUSXML2CPP_ADAPTOR_HEADER_FLAGS.
Change-Id: Ibbe812fbe4912acfd2c9721b5193727ae0c0ade3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
When QGraphicsView has sceneInteractionAllowed == false (e.g
when dragMode == QGraphicsView::ScrollHandDrag), all touch
events are accepted. This is wrong, and will stop mouse synthesising
from happening on touch platforms. This in turn will make
ScrollHandDrag not work (since no mouse events will come through).
This patch will call QEvent::ignore() if the touch event isn't send
to the scene, which will cause a mouse event to be synthesised.
Note that according to http://doc.qt.digia.com/qq/qq11-events.html
the correct approach would probably be to just return 'false', rather
than calling QEvent::ignore(). But this logic is not followed
consistently elsewhere (e.g in QApplication::notify), so I choose
to follow what the code actually expects for this bugfix.
Change-Id: Ida777647134c41661bab156d7b164ebd882a6bb1
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
One reason is when we are using XInput 2.2, because touch devices
will then generate touch events only. For the other X11 scenarios,
X11 does its own mouse emulation.
QPlatformIntegration::styleHint() wasn't overridden yet. The remaining
hints are TODO for now.
Change-Id: I2e444a00a18b33ed840ebfa8d8218655c2c39aad
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
It's possible to override event() to receive the QCloseEvent and
do event->ignore() to prevent the window from closing.
Task-number: QTBUG-31019
Change-Id: I9abed47fca02a002b78727f98d678a824854adfc
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
-the externalsites from qtdoc is being removed and the new copy is in
qtbase/doc/global.
Change-Id: I8f509acf05c0e1f399205daf4e4831cf46475746
Reviewed-by: Venugopal Shivashankar <venugopal.shivashankar@digia.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
-"qt-sql" removed in qtdoc
-no longer needed because "Data Storage" and Qt SQL pages already serve
as the main introduction to SQL support in Qt
Change-Id: I7384ae04ab4c09ecc9d76668e4e7f836095066c1
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
defaultFramebufferObject() may be called from anywhere, at any point,
not just makeCurrent(). One example is the glyph-cache, which uses it
to re-bind the default FBO after generating the texture cache.
If the default FBO had already been created, but the render-buffer was
out of sync with the window size, we would end up in the resize code
without the correct context current, and without the render-buffer's
owning FBO bound. This caused "Failed to make complete framebuffer
object 8cd7" warnings at runtime.
We now make the context current and bind the FBO, even though it might
already be bound and the context current from makeCurrent(), or when
initially creating the FBO. For the future we should move the whole
resize logic out of defaultFramebufferObject() and call it from
makeCurrent(), or possibly [EAGLView layoutSubviews]. That's a
higher impact change though, which we reserve for the 'dev' branch.
Change-Id: I50ea949c12a02ad1af6ec9fdc3215d5da85b324f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
OpenGL ES2 doesn't support NPOT textures in combination with GL_REPEAT,
so for OpenGL ES2 we use a custom program that emulates repeat by taking
the fractional part of the texture coordinates.
This is not enough though, as merely setting GL_TEXTURE_WRAP_x to GL_REPEAT
with a NPOT texture is an error in some implementations, so we have to
guard the call to updateTextureFilter() in updateBrushTexture() with
a check for OpenGL ES2 and use GL_CLAMP_TO_EDGE instead.
This fixes missing/black backgrounds in the diagramscene example on iOS.
Change-Id: I5020090b5f17faeb06dcab9dc0292459e021af30
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Even though the intentions of this warning were good, the warning
was a bit harsh. In addition, in certain circumstances
(like the autotest demonstrates) we could end up calling object()
on an interface where the object was in the destructor. This
could happen because: *after* we got the destroyed() signal, the
widget would still notify the accessibility framework of a FocusOut
event.
Since the code even called object() from isValid(), we could not even
(as a defensive measure to circumvent this issue) check the isValid()
of an interface without getting this warning (duh).
So - for isValid(), the warning is not needed at
all, since the caller will of course check the result of isValid() and
act accordingly.
As for the result of object(), it should always be a pointer, but it
might point to a partially destroyed object. To detect this, you simply
check isValid() first:
if (iface->isValid())
doStuff(iface->object());
Change-Id: I206307fe618806133d8c6bc338c412d0009d7181
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
I also modified tst_QDnsLookup the test to use ';' as a separator as
opposed to spaces because I added MX and SRV records with multiple
RRs.
Change-Id: I62c7b6ad342c1bb23c4d9ac9730e35ab422e3ea2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard J. Moore <rich@kde.org>