| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.gitignore
configure.exe
src/corelib/concurrent/qtconcurrentthreadengine.h
src/corelib/global/qnamespace.h
src/gui/graphicsview/qgraphicssceneevent.h
src/gui/kernel/qapplication.cpp
src/gui/kernel/qapplication.h
src/gui/kernel/qapplication_p.h
src/gui/kernel/qapplication_qws.cpp
src/gui/kernel/qwidget.h
src/gui/painting/qpaintengine_raster.cpp
src/gui/text/qfontdatabase.cpp
src/network/access/qnetworkaccesshttpbackend.cpp
tests/auto/network-settings.h
tests/auto/qscriptjstestsuite/qscriptjstestsuite.pro
tests/auto/qvariant/tst_qvariant.cpp
|
| | |
| |
| |
| | |
We don't want to pull in too much if we can avoid it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This enum indicates what kind of device generated the touch event
(TouchScreen or TouchPad). We use this information to control how touch
events are sent, specifically we restrict touch events to a single
widget/QGraphicsItem on touch-pads, since there is no direct
relationship between the physical touch location on the pad and the on-
using the touch-pad).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This introduces normalizedPos(), startNormalizedPos(), and
lastNormalizedPos() in QTouchEvent::TouchPoint, and must be set by the
implementation before being fed into Qt.
We are assuming and hoping that these functions will make it easier to
implement certain types of gestures (especially on a touchpad).
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We now send both types of events, i.e. accepting TouchBegin doesn't block mouse events anymore. We
are also introducing the idea of a "primary" touch point, which is the one that the system is also
generating mouse events for.
This lets us reuse existing mouse event code while still being able to add multi-touch support.
|
| | |\
| | |
| | |
| | |
| | | |
Conflicts:
src/gui/graphicsview/qgraphicsscene_p.h
|
| | | |
| | |
| | |
| | | |
Reviewed-by: Trust Me
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
the API for these 2 classes is identical, the implementation is almost
identical, they share the same data structures, so bite the bullet and
merge them.
this means we go back to using screenPos() instead of globalPos()
again
|
| | |
| |
| |
| |
| |
| | |
rects instead
these are more useful, as already shown in the fingerpaint example
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Don't have QGraphicsSceneTouchEvent::TouchPoint inherit from
QTouchEvent::TouchPoint. The only reason to do this is to support an
implementation trick, which can be done another way (see below). This
means we have to essentially duplicate the API in the GraphicsScene
variant.
2. Don't use a list of pointers to touch points in QTouchEvent and
QGraphicsSceneTouchEvent. This means we have to make the TouchPoint
classes implicitly shared (and the effect of the previous trick of
static_casting the widget touch point to a graphics-scene touch point
can be emulated by sharing the d-pointers between the classes).
3. QEvent::RawTouch isn't really an event type, it's a
backdoor. Remove it and export the bool
qt_translateRawTouchEvent(QList<QTouchEvent::TouchPoint>, QWidget *)
function instead.
4. Rename QTouchEvent::TouchPoint::area() to size() (which is more
clear as to what the function
returns). QGraphicsSceneTouchEvent::TouchPoint gains size(),
sceneSize(), and screenSize() functions (the actual translation from
screen to scene to item still needs to be implemented).
|
| | |
| |
| |
| | |
Add QTouchEvent::TouchPoint::area() and implement support for it on Windows
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This new function returns a bitwise OR of all the touch point states for
the event. This makes it easy to see if a certain type of state is present
or not without the need to loop over all touch points.
QApplication and QGraphicsScene need to build this state when dispatching
the touch points. This also fixes the ASSERT bug that Denis found when
trying to send multiple touch presses in a touch begin event.
|
| | |
| |
| |
| |
| |
| | |
We'll use the \internal functions to modify it instead. This should make it easier
for people to implement support for touch events outside of Qt itself (still need to
somehow expose the logic for dispatching the touch points to the correct widgets though).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This required a larger change to the kernel and graphicsview directories to
make this as efficient as possible:
1. QTouchEvent::TouchPoint becomes the base for
QGraphicsSceneTouchEvent::TouchPoint - this means there is one private for
every touch point, and we can store both the screen and scene coordinates
in one place. Converting a QTouchEvent to QGraphicsSceneTouchEvent becomes
nothing more than casting the QTouchEvent::TouchPoints to
QGraphicsSceneTouchEvent::TouchPoints.
2. The logic that we use in QApplication to convert WM_TOUCH* messages to
QTouchEvents is essentially duplicated (with some minor changes) to
QGraphicsScene so that it can support mulitple touch item targets. I
will have to investigate how I can perhaps merge some of the duplicated
code.
QEvent::GraphicsSceneTouchBegin propagation is not implemented yet, and will
come in a later commit
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Each gesture can now be accepted separately and not accepted gestures
will be propagated to parent widget that are subscribed to them.
Added an internal flag to specify that gesture is a "singleshot" - aka
if the gesture is not continious and will not have a GestureStarted
state, but only GestureFinished.
Asynchronous gestures still need to fixed, as well as QGraphicsView.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Gesture is now associated with a target widget and whenever several
gesture events occur at the same time if they are supposed to be handled
by different widgets, each widget will receive only gestures related to
itself.
For example this makes possible to use gesture framework with multitouch
when user interacts with two widgets at the same time.
GraphicsView implements is not implemented yet.
|
| | |
| |
| |
| | |
are QObject now everything is much simplier.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Gesture types are now separated to internal ones, which are listed as
enums (though they might be converted to strings internally), and
third party gestures which are referenced by strings.
From now on QGesture objects derive from QObject, which means third
party gesture recognizer developers can use QObjects property system
to store custom data inside QGesture without need to subclass it.
Some functions were renamed to show their purpose more clear.
|
| | |
| |
| |
| |
| | |
providing some additional info (like a widget that received a gesture
- for coordinates conversions).
|
| | |
| |
| |
| | |
Fixed missing const specifiers.
|
| | |
| |
| |
| |
| | |
This is a squashed merge of all of the changes in the maemo-gestures
branch on-top of the qt/4.5.0 branch.
|
| | |
| |
| |
| |
| |
| |
| | |
widgets simultaneously
This is a first attempt, and it works, but it will need to be cleaned
up to remove as much state from QWidgetPrivate as possible.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
behavior is similar to that of QGraphicsScene mouse events: the first
touch event (the TouchBegin) is propagated to all parents. if a widget
accepts the event, it will receive all other touch events (the
TouchUpdate and TouchEnd events). If no widget accepts the TouchBegin,
then we will fallback to normal mouse events (TBD).
|
| | |
| |
| |
| |
| |
| | |
these events contain a list of all touch points. note that the
coordinates for QTouchEvent are floating point, since many devices
offer sub-pixel resolution.
|
| | |
|
| |
|
|
|
|
| |
This is required for S60 FEP.
RevBy: Simon Hausmann
|
| |
|
