AnchorAttribute was removed as part of the Qt3Support cleanup.
Change-Id: I58d8e471d4bc1af420ec8eaab6d34c1718b30382
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
Ensure the initial size is valid, since we store it as normalGeometry
below.
Task-number: QTBUG-26226
Change-Id: I3a55c389a48504699942930063089c80657687a0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Under Windows CE the top title window bar needs
to be taken into account when creating a window,
so the Style WS_OVERLAPPED needs to be passed to
AdjustWindowRectEx, to get the right size of the
window. For the desktop the documentation says,
that you should not pass the WS_OVERLAPPED flag,
but wince does not talk about this.
Change-Id: Id8c9d28b7aa04a9920e4cb81ac11463d9717a0e7
Reviewed-by: Björn Breitmeyer <bjoern.breitmeyer@kdab.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
A virtual method was reimplemented to return an always-empty string,
probably a leftover from a refactoring.
This fix showed that tst_qwidget_window was buggy: between Qt4 and Qt5,
a "Before" became "After", which made "Before" unused, and was masking
the fact that the app name was empty by default. In addition, the
earlier Qt5 change that made the app name default to argv[0] now requires
updating this test, now that it's actually working.
Change-Id: I5360026821a9b95bedd0ff09dba3d51a22e542b7
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@nokia.com>
As long as QToolButtonPrivate is declared in .cpp file,
this constructor is useless.
Change-Id: Ibbeaf291b88b3b203e5107e0227d68e65cbb9eee
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Jeremy Katz <jeremy.katz@nokia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Use code from QTestLib to wait for the Window to show up.
Change-Id: Ib674f3eb7a6c32cad1d502caefe7d4b073754e73
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
if() seems to behave differently with macro parameters compared to
variables set with set().
Change-Id: Ieb9544b8c3187579fd4cfe25e2c2afa3f349eba6
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This makes it possible to add API for setting the restore policy
per state, or even per property assignment (QTBUG-17861).
This change is fully source compatible with Qt4.
Change-Id: I53628546b070f6fc84891f86e7ad7bd8ef5ba285
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Back when QStateMachine was changed to inherit QState, this
constructor was conveniently left out because setting the state
machine (root state) to be a parallel state group didn't actually
work. But as of commit d281aa6936,
it does work, so add the missing constructor.
Task-number: QTBUG-15430
Change-Id: I68c599baa0ef1bfc869195140cf5daf645e75b8b
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
it's a tad insane to expect the user to do that
Change-Id: I75c68f2a28656c9ba2e3fabcc79718b899b29ce7
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
under extremely rare circumstances this would have actually failed
Change-Id: I4132d0f82e9f924e92e9e96f6d34451c94a67201
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
When accessing a fallback engine, we always need to call
ensureEngineAt() to make sure it's loaded.
Change-Id: Ib27e34137cfe8a3dd2b358aef3b3296a4ca52478
Reviewed-by: Jiang Jiang <jiang.jiang@nokia.com>
This is just for completeness of the understanding of the limitations
of private signals. There are no private signals in Qt which have
overloads.
Change-Id: Ic34c555aea360ee34beec796e597657888573da9
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
In this change:
dba22bc036
we actually do not need the sync.profile change.
The header is already in QtGui - and it caused compiler warnings
when Qt/tests are compiled. The troubled includes are of type
<qstandarditemmodel.h> where Wigets are first in the include path.
Change-Id: Iff17f6ddb6c6282d41a08b53438b7aec786f12a9
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
When the pushbutton is shown, it will generate both a ShowEvent and
a StateChange with active=1 (because it is a top level window).
This patch relaxes the reqirement in which order events are delivered.
Ideally the order should also relied on, but I'm not sure if that
is feasible due to differences among window managers across all
platforms.
This got provoked by codereview.qt-project.org/#change,26014
Change-Id: I96159fbb1b64f0ca8d13833d8a4c6799c655afc2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
This is the result of running util/normalize --modify
from Qt 4.7 with manual review.
Change-Id: I9229c3c52ba785194469ad51aba0c3af0c058894
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
This is the result of running util/normalize --modify
from Qt 4.7 with manual review.
Change-Id: I7c9539056a4434ed10a0255152eac1781f7833be
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This is the result of running util/normalize --modify
from Qt 4.7 with manual review.
Change-Id: I4afac23e897404ac7efb5b4a89493a2c15e3c670
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Multiple calls to find_package(Qt5Core) would otherwise attempt to
create multiple targets of the same name.
Change-Id: I5639671fec66d4dd62dcce018dea5d18dcfd3dc3
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
With the recent refactoring in qtdeclarative for the handling of touch
and mouse events, QQuickCanvas automatically transforms touch events in
mouse events too.
It means that since we do something similar in the platform plugin, in
the case of QQuickCanvas the mouse event is duplicated. It it fine
except that having mouse event, touch event, mouse event in that order
is likely to mess the states of some elements. It happens to be the case
for MouseArea which will discard the second mouse event in the case of a
press, and because of that not receive the other events.
By changing the order in the plugin, we ensure getting events in the
following order: touch event, mouse event, mouse event. In the case of
MouseArea, since the press event will be accepted with nothing in
between, we'll keep receiving the other events.
Note that we can't simply remove the mouse event simulation on our side,
otherwise we'd break QWidget support.
Change-Id: If08fe0d97c6d60d0f858b228a014d94bc86dcf6f
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
It's silly to call one virtual function plus one function that
walks the inheritance chain, on every signal transition connect
and disconnect, when the method offset of the internal
QSignalEventGenerator class cannot change.
Change-Id: Ic4e83bdc6ab445ea8ca00f3d8da3031250621e2f
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
This is much faster than the string-based api.
Change-Id: Id7ba76aee3346dd90412ec5c8505329360aae937
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Since Qt's connections are thread-safe, QStateMachine's plumbing
around them should be thread-safe too.
Change-Id: I8ae91c2edc2d32ca4ed4258b71e5da22de30ed91
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
By default, QStateMachine lazily registers signal transitions (i.e.,
connects to the signal) when the transition's source state is
entered. The connections are established in Qt::AutoConnection mode,
which means that if the sender object lives in a different thread,
the signal processing will be queued.
But if a sender object's signal is used in an out-going transition
of the target state of the queued transition, it's possible that a
second signal emission on the sender object's thread will be
"missed" by the state machine; before the machine gets around to
processing the first queued emission (and registering the
transitions of the new state), a sender object on the other thread
could have emitted a new signal.
The solution employed here is to eagerly register any signal
transition whose sender object is on a different thread; that is,
register it regardless of whether the transition's source state is
active.
Conversely, when a machine's transitions are unregistered (i.e.,
because the machine finished), signal transitions with sender
objects on other threads should be left as-is, in case the machine
will be run again.
This doesn't solve the case where the sender object is moved to a
different thread _after_ the transition has been initialized.
Theoretically, we could catch that by installing an event filter
on every sender object and handle the ThreadChange events, but
that would be very expensive, and likely useless in most cases.
So let's just say that that case isn't supported for now.
Task-number: QTBUG-19789
Change-Id: Ibc87bfbf2ed83217ac61ae9401fe4f179ef26c24
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Split the guts of registerTransitions() into a registerTransition()
function. This allows a particular transition to be registered,
instead of walking the source state's whole list of transitions
every time.
Move the logic for determining whether a transition should be
registered to the state machine, since that's also where the actual
registration takes place.
Change-Id: I0496dee9454cd77b62cf2768942a82a96b320744
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
Fix coding style, constness, m-prefix for member variables.
Change-Id: I9d75b410b398e5c3084b086b41884f2a0ddd6e5e
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
Some of the transition constructors didn't call the maybeRegister()
function, causing the transitions to be ignored if they were created
when the state machine was running and the transition's source state
was active.
Added tests that cover all possible cases.
Change-Id: If1b593b127bd719e3be4e5a2e6949a780c4e97c3
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
If the sender object was set, but not the signal signature, the
registration would proceed anyway, producing a strange warning like
QSignalTransition: no such signal: MyObject::
Change-Id: If0b113bdb60dd770d60b0d38d509b673e9d8c5eb
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
The originalSignalIndex member was not set if the signature had to be
normalized. This caused the SignalEvent passed to onTransition() to
report a signal index of -1.
Improve the signal transition tests so they check both the event
passed to eventTest() and onTransition().
Change-Id: I5331fd1944d53310b6d11eb2fd8713b80faa53a1
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@nokia.com>
There's one in corelib that has a comment
// slower due to signature normalization at runtime
I obviously didn't change that one.
This is the result of running util/normalize --modify
from Qt 4.7 with manual review.
Change-Id: I0ffb2305800a9cb746b7f8a4eb710702d64f1b92
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
