| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
We don't keep the state from the previous events anymore, so the 'down' variable is useless (and actually caused problems).
|
| |
|
|
|
|
|
| |
this makes it possible to have a little code as possible feeding the
raw events into Qt (and tests/auto/qtouchevent passes now too :P)
|
|
|
|
|
| |
this makes sure that we get the proper start/last position maintenance
and global->local translation.
|
|
|
|
| |
Qt::WA_AcceptTouchEvents
|
|
|
|
|
| |
The mask isn't used and changing it doesn't do anything, so this is
just a cosmetic/clarification change.
|
| |
|
| |
|
|
|
|
| |
how embarassing :/
|
|
|
|
| |
Need to move the extern declaration out of the QtTest namespace
|
|\ |
|
| |
| |
| |
| |
| | |
test that sending the TouchBegin to this widget both succeeds and
accepts the event
|
| |
| |
| |
| | |
the event is accepted by default, but no handled
|
| |
| |
| |
| |
| |
| |
| | |
start off by testing basic behavior:
1. touch events are disabled by default
2. touch events are automatically accepted when enabled
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
| |
After an API review round, we agreed that it makes sense for the
TouchBegin event to default to accepted if the widget has subscribed
to receive touch events.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some older versions of the Bourne shell (/bin/sh) don't
support the ! operator for negating the exit code of a pipeline.
In particular, this is true on certain (all?) Solaris 9 platforms.
The patch replaces all occurrences of the ! operator with equivalent
(but slightly less elegant) expressions that test the $? variable instead.
Reviewed-by: msorvig
|
| |
| |
| |
| |
| |
| |
| | |
As checked in was compiling with QDataStream(QByteArray *, int) and
that method is only available when compiling with qt3 support.
Reviewed-by: Julian de Bhal
|
| |
| |
| |
| |
| |
| |
| | |
seem fixable easily)
Merge-request: 594
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |
| |
| |
| |
| | |
Merge-request: 594
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |\ |
|
| | | |
|
| | |
| | |
| | |
| | | |
Reviewed-by: TrustMe
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Whenever an argument failed to marshall, this assert would be
triggered. It's technically an error in the application, but it's hard
to track it down. So remove it and let the execution continue (the
function returns false indicating failure already and there's a
warning from the marshalling code itself)
Reviewed-by: TrustMe
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch prevents the eventloop from waking up needlessly.
Without this patch the event loop will not sleep at all if a 0-timer is already 'inTimerEvent'
Merge-request: 550
Reviewed-by: Olivier Goffart <ogoffart@trolltech.com>
|
| | |
| | |
| | |
| | |
| | |
| | | |
We were saying that it connected to accepted it all these cases, but it
actually is doing some nice magic that makes sense assuming you document
it.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
No progress bars on the mac show text and it would be bad if we allowed
it. There's nothing stopping people from connecting the valueChanged()
signal to a slot and have a real label layed out correctly that actually
updates with the amount of time it takes to complete, etc. This is more
what they do on Mac OS X if they decide to show a label.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
QMotifStyle
Same fix as in e9a7e43031d7c1ee712e43be682c4e2c183759c4 but with motif
Reported by https://bugs.kde.org/show_bug.cgi?id=193911
Task-number: 255138
Reviewed-by: jbache
|
| | |
| | |
| | |
| | | |
Reviewed-by: TrustMe
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Using a OK/Cancel message box is weird for a yes/no question, esp. on a
Windows CE device where such a message box doesn't have real push
buttons but must be OK'ed / cancelled via system buttons in the title
bar.
Task-number: 255112
Reviewed-by: thartman
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This was quite a bug and it showed to some issues that I hadn't taken
into account when doing the initial port to Cocoa. The issue was that we
weren't "merging" items into the application menu if an item had already
been associated with it. Which seems OK for applications that create one
window with one menubar, but breaks down horrible when you have multiple
windows with each having their own menubar. The result is that items in
the application menu potentially go to the wrong window (and the
potential crash). Since there can only ever be one "Quit", "About", or
"Preferences" menu item in Cocoa, we need to make sure that we keep
these items in sync whenever we switch the menubar or remove actions
that are being deleted. That's what we do here.
FWIW, QActions with "ApplicationSpecificRole" for their menu role have
potential to cause memory leaks or other bugs if abused. If you are a
happy open source hacker who wants a thankless job, solving them would
get you lots of goodwill in my book.
Task-number: 255038
Reviewed-by: Richard Moe Gustavsen
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes a problem where qmake would not compile when it was built
from it's .pro file because this method uses the pre-compiled header.
This header was causing a compile error in qlocale.cpp because
qtextstream.h was included and this includes qlocale.h. The problem in
qlocale.cpp was that it uses a define called QLOCALE_CPP to enable
extra functions in the class declaration, but the pre-compiled header
was preventing the qlocale.h from being re-processed and therefore the
function was never compiled in.
Reviewed-by: Marius Storm-Olsen
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The blend functions assume the width / height of the images being
blended to be greater than 0. A width of 0 caused the first iteration of
a duff's device memcpy (QT_MEMCPY_USHORT) to be executed, thus blending
8 pixels instead of none.
BT: yes
Task-number: 255014
Reviewed-by: Trond
|
| | |
| | |
| | |
| | | |
Reviewed-by: TrustMe
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The BOM was created correctly, but half of the BOM was then overwritten
by the converted data afterwards.
Also made the autotest also do reverse encoding tests where possible.
Task-number: 255095
Reviewed-by: lars
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The tick timer is always active, even if the moving gree Qt logo is not visible.
But the code that is supposed to pause it when the app loose the focus doesn't works if
the moving Qt logo is not visible.
Also the call to syncX makes Xorg takes lot of cpu.
It doesn't fix the fact that the timer is still running while the green logo is not visible,
but at least doesn't take the cpu anymore if qtdemo loose the focus.
Task-number: 255020
Reviewed-by: Richard Moe Gustavsen
|
| | |
| | |
| | |
| | | |
Reviewed-By: TrustMe
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|