| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Should *not* be used as a softkey.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
| |
If toplevel window is raised, the whole application is now raised to
foreground.
Task-number: QT-2162
Reviewed-by: axis
|
|\ |
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Softkeys have a QAction that is related to some action widget.
The initial state of the action was set according the state of action
widget (enabled/disabled). Now, if action widget's state changes,
the softkey's action remain in the initial state.
This was fixed by removing the enable/disable from the QAction and
instead use the real state of action widget when handling the
command of softkey.
Task-number: QTBUG-4619
Reviewed-by: Janne Anttila
|
| |\ |
|
| | |\
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/gui/kernel/qcocoaview_mac.mm
src/network/access/qhttpnetworkconnection.cpp
src/opengl/qgl_qws.cpp
src/opengl/qglpixelbuffer_egl.cpp
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The gobal variable which stores the current mouse event can be updated
before dragImage() call(blocking) is finished. So make a local copy of
the information required by the QDragManager::drag().
Task-number: QTBUG-4814
Reviewed-by: MortenS
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
New behavior is to turn them off when inputting numbers or hidden
text, which is the way it was in Qt 4.5.
Task: QT-1938
Task: QT-2257
RevBy: Prasanth Ullattil
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Did the long awaited "refactor me" in QSymbianControl::HandlePointerEvent
Pointer is grabbed by MousePress, and released by MouseRelease - unless
already globally grabbed.
Pointer events are routed to the widget that grabbed the mouse.
Task-number: QTBUG-4695
Task-number: QTBUG-4674
Reviewed-by: axis
|
| | | | |
|
| |\ \ \
| | |/ /
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/corelib/kernel/qcoreevent.cpp
src/corelib/kernel/qcoreevent.h
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Custom window surfaces, graphics systems, and Qt/Embedded screen
drivers often need to access QPaintDevice::metric(), but it is
protected. Hence the growing number of friends in QWidget and
QImage. The qt_paint_device_metric() function provides a more
future-proof approach that doesn't require lots of friends.
Reviewed-by: Gunnar
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
On Cocoa, we sometimes need to block sending posted events
(because we need to flush the event que now and then without
touching Qt events). But we forgot to do same for timer callback.
So this patch makes sure that we dont send the timer event
immidiatly if we are just flushing the event que.
Rev-By: brad
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
to zero only if currently focused
Reviewed-by: axis
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
dd9d8693 added some checks causing SetGestureConfig to not be
initialized to 0. Thus it gets derefenced and causes crashes on all
WinCE applications.
Reviewed-by: denis
Reviewed-by: ninerider
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Make sure that we cancel the pan gesture if the user starts
to press several fingers on the trackpad, and the gesture has
not yet got a chance to start
Rev-By: trustme
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Earlier we returned a copy of the Qt modifiers. This patch fixes the
call to return the real native Symbian one.
RevBy: Sami Merila
|
| | | |
| | | |
| | | |
| | | | |
Rev-By: trust me
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The reason for the bug is that we call _quit_ on the eventloop
just _after_ posting the deffered delete event (from inside
deleteLater function, ref the test where it fails,
tst_qapplication.cpp:1242). And the point is, even if the loop
level tells us that we _can_ delete the object in this case, the
'quit' tells us that we should not process _any_ events (until we
get a call to processEvents again).
So this patch makes sure that we don't call sendPostedEvents from
the eventDispatcher if it is interruped.
Rev-By: brad
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Accidentally used git commit -a when should have used only git commit :(
This reverts commit 9c6e466dc09813dd4a641b2cf385f35ac99346f5.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
S60 port was supporting QCursor(QPixmap) where the pixmap didn't have
any mask or alpha channel, and generating a mask using
QPixmap::heuristicMask. Now changed to draw the cursor opaque in this
case, which matches the behaviour on other platforms.
Also it failed horribly with shaded backgrounds e.g. draggable icons demo
Task-number: QTBUG-4761
Reviewed-by: axis
|
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: TrustMe
|
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: Trust Me
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Default action was always MoveAction, which removed the data from the
source widget, even if not accepted anywhere.
Now uses the default action from the base class manager.
Task-number: QT-736
Task-number: QTBUG-4356
Reviewed-by: Aleksandar Sasha Babic
|
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: trustme
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When a gesture recognizer claims to be in Finished state without any
Triggered states before, that probably means that was a singleshot
gesture that has started and ended right away, so we'll send a fake
gesture in the GestureStarted state.
Reviewed-by: trustme
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Deleting qt_desktopWidget eventually ends up to QSymbianControl
destructor. Calling setFocusSafely from QSymbianControl destructor
causes a new events to be posted to event queue. Posting events tries
to wakeup event dispatcher, which was deleted in QApplication
destructor before calling delete for qt_desktopWidget. This makes
application to panic.
The fix is to change is_app_closing and is_app_running flags to correct
state immediately after event dispatcher is closed down, and check the
is_app_closing flag in QSymbianControl destructor.
The change fixes panic in qapplication::testDeleteLaterProcessEvents,
and otherwise QApplication and QWidget autotest results are same as
before change.
Reviewed-by: Miikka Heikkinen
Reviewed-by: Brad
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Forgot to remove the declaration from a source file because of a bad merge.
Reviewed-by: Bradley T. Hughes
|
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: Olivier Goffart
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The constructor that accepts a gesture type is not needed because the
gesture type id will be generated by Qt and assigned to the QGesture
object when a custom gesture recognizer is registered within the
framework.
Reviewed-by: trustme
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Implemented gestures using gesture events and separate
QGesture/QGestureRecognizer classes.
Reviewed-by: trustme
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Set the softkey container window to be selectable even when pointer
is grabbed (via window server setting)
Task-number: QT-2203
Reviewed-by: Espen Riskedal
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
until control returns to the event loop.
This is necessary because reparenting can be triggered from the context
of a control's event handler. If reparenting causes that control to be
deleted, a crash can result.
Task-number: QTBUG-4664
Reviewed-by: axis
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
to zero only if currently focused
Reviewed-by: axis
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is sent to a native widget when its window system identifer has
changed.
This is motivated by the fact that, on Symbian, the native window
system identifier may change in situations other than a change of
parent widget. Specifically, calling QWidget::setParent, passing in
the widget's existing parent, but OR-in Qt::Window into the window
flags, causes a new native window handle to be created. Furthermore,
because of the fact that Symbian does not allow existing windows to be
reparented, any descendents of the original widget which are also
native, must also be given new window system handles.
Note that setWinId does not send a WinIdChange event if the incoming
winId is zero. This is because setWinId(0) is only called in two
situations:
1. During native widget destruction
2. During re-creation of the winId for a native widget
Task-number: QTBUG-4664
Reviewed-by: Bjoern Erik Nilsen
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Both reparenting and modification of window flags are done by calling
QWidget::setParent. If either the parent changes, or a non-top-level
widget becomes top-level (as a result of OR-ing Qt::Window into its
window flags), a new native window ID is created for the widget. The
Symbian implementation of setParent_sys had a flaw which manifested
itself in the following situation:
1. We start with a native widget X, and its child Y, which is also
native. There exist parent-child relationships between the associated
CCoeControl instances, and the native windows (represented by RWindow
handles).
2. X gets a new native window created as a result of a call to
setParent.
3. QWidgetPrivate::reparentChildren calls SetParent on Y's control, to
re-establish the parent-child relationship.
The problem is that the window owned by Y's control now has no parent,
so if we try to re-size the widget, the window server panics the client
thread (WSERV-52).
Because Symbian does not allow existing windows to be re-parented, and
nor does it allow a window-owning control to re-create a new window,
the only way to provide Y's window with a parent is to destroy the
control and create a new one, passing in X's new window to the
CCoeControl::CreateWindowL function.
The changes made are as follows:
a) QWidgetPrivate::reparentChildren is therefore modified to call
create_sys, with destroyOldWindow set to true.
b) QWidgetPrivate::create_sys is modified to take account of the value
of this flag in all cases. (Previously it only did so if a new WId was
passed in by the caller).
c) The call to setWinId is delayed until the control and window are
fully initialized. This is to allow us to emit a new event,
WinIdChanged, from setWinId, in order to inform the widget that its
winId has changed.
d) QWidgetPrivate::activateSymbianWindow is modified in order to
support this change of call ordering.
Note that QWidgetPrivate::create_sys requires some re-factoring in
order to remove the redundancy between the top-level and child widget
cases.
Task-number: QTBUG-4664
Reviewed-by: axis
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Don't create native windows when setting the window title, delay the
creation until the native window is needed. If a user really needs the
window to be created, he/she can call winId() on the widget or set
Qt::AA_ImmediateWidgetCreation.
Reviewed-by: Bradley T. Hughes
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
The native child widgets need to inherit the parent's visual in order to
have a translucent background as well.
Reviewed-by: Trond
|
| | |
| | |
| | |
| | | |
Reviewed-by: David Boddie
|
|\ \ \
| | |/
| |/|
| | |
| | | |
Conflicts:
src/gui/itemviews/qheaderview.cpp
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For some strange reason, I get the following message if I press a
non-numerical key on the SIP of a Samsung Omnia device, running Windows
mobile 6.1:
WM_KEYDOWN
wParam == 0
lParam == 1
That message is invalid. We must ignore it.
Reviewed-by: mauricek
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Incorrect optimisation - for popup windows, Qt's focus is moved before
hide_sys is called, resulting in the popup window keeping its elevated
position in the CONE control stack.
This can result in keyboard focus being in an invisible widget in some
conditions - e.g. QTBUG-4733
Task-number: QTBUG-4733
Reviewed-by: axis
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It turns out that scrolling appears to be slow when using
non-mac mice with the carbon build. This patch introduces a
an acceleration algorithm that closer resembles the one
used by Cocoa.
Rev-By: prasanth
|
| | |
| | |
| | |
| | |
| | |
| | | |
Added the missing defines
Reviewed-by: Denis
|
| | |
| | |
| | |
| | | |
Reviewed-by: Jens Bache-Wiig
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a backend for QFileIconProvider in the platform plugin
Also change the QIcon::fromTheme backend in the platform plugin:
On KDE, we unfortunately can't use KIcon as backend, as the current
API doesn't let us know easily (and quickly) wether we should use
the fallback or not (KDE always fallback to the question mark
"unknown" icon)
So we will use the QIconLoader even on KDE.
But we need to make sure that the theme name and the icon search paths
are correct. Ask that to the platform plugin
Reviewed-by: Jens Bache-Wiig
|
| |
| |
| |
| |
| |
| |
| | |
Missing header file, resulting in compiler error about returning
an incomplete type.
Reviewed-by: Trust Me
|