| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/gui/kernel/qcocoaview_mac.mm
src/network/access/qhttpnetworkconnection.cpp
src/opengl/qgl_qws.cpp
src/opengl/qglpixelbuffer_egl.cpp
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
geometry() is in parent coordinate. We want the coordinate in viewport
coordinate.
There is an offset (the header geometry) between the two.
So the first item was not refreshed.
(Regression because of e5b32fbe0efc8 and a54c18e27bbb)
Reviewed-by: Gabriel
Reviewed-by: Alexis
Task-number: QTBUG-4849
|
| | |
| | |
| | |
| | |
| | |
| | | |
Test failed on different styles such as Windows Mobile.
Reviewed-by: Ossi
|
| |\ \ |
|
| | |\ \ |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Logic copied from the QMenu test
Also do the same in the QButtonGroup test
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
machines to complete those tests before being killed by pulse.
Reviewed-by:TrustMe
|
| | |\ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
no crap before.
Reviewed-by:ogoffart
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Reviewed-by: Gabriel
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When the DisplayRole is identical for two or more items, any
modification of one item (e.g. backgroundColorRole) may trigger a
re-ordering, which is obviously not an behaviour to be expected.
Same fix as the one used for QTreewidget in
c9eacfa1c791e2d228a3c8f0c119d02d7f46ee02.
Task-number: QTBUG-4856
Task-number: 262056
Reviewed-by: Olivier Goffart
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Keep the sorting states in sync with the header when
setting custom headers
Reviewed-by: Gabriel
Task-number: QTBUG-3128
task-number: 234926
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Cocoa doesn't support regions update and always update the
bounding rect (see comment in QWidgetPrivate::update_sys
in qwidget_mac.cpp)
Change tests that checked that we get the exact regions.
Reviewed-by: MortenS
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
the palettePropagation test tests that the palette does not
propagate from the widget to the proxy.
And on Mac, the default palette for the line edit is not the
same as the default palette
Reviewed-by: Alexis
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
toEncoded was returning an empty host instead of [::ffff:129.144.52.38]
Merge-request: 1735
Reviewed-by: Olivier Goffart <ogoffart@trolltech.com>
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When making a rubber band selection while Control is pressed in an
itemview with extended selection, make sure that the selection state
of the items inside the rubber band is toggled.
This ammend commit 0644e3dce532b1df00a77d3a30c61d6b75d3ff30
Merge-request: 1759
Reviewed-by: Olivier Goffart <ogoffart@trolltech.com>
Reviewed-by: Gabriel
Task-number: QTBUG-1435
Task-number: 191545
|
|\ \ \ \ \ \
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
src/corelib/kernel/qcoreevent.cpp
src/corelib/kernel/qcoreevent.h
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
While a rational number is a common way to represent a frame rate,
QPair<int, int> isn't a proper numeric type meaning it can't be used as
anything more than an identifer for an exact frame rate without being
converted to a real, or extending it to a proper rational type.
Rev by: Justin McPherson
|
| | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Made QComboBox::removeItem() do nothing instead of asserting if index
is out of range.
Reviewed-by: Andy Shaw
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
On Symbian, QDir::rootPath() and QDir::home() are same.
RevBy: Janne Anttila
|
| | | | |
| | | | |
| | | | |
| | | | | |
RevBy: Janne Anttila
|
| | |/ /
| |/| | |
|
| |\ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
there was a race condition which on Windows often made the test fail
Reviewed-by: Markus Goetz
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | |\ \ \
| | | |/ / |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
QPalette() and QApplication::palette("QLineEdit") are not the same on Mac
We really want QPalette() here because the graphics widget is not supposed
to inherit from the widget it is proxying.
Reviewed-by: Alexis
|
| | | |\ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Keyboard navigation didn't work in the following cases:
- The last column was disabled and we pressed the tab key when at the 2nd
last column. (See ref. task).
- Spans with their anchor column or row hidden or disabled.
- Navigation would not preserve the original row/column when traversing a
span horizontally/vertically.
Auto-tests submitted with this commit.
Task-number: QTBUG-3878
Reviewed-by: Olivier
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
On mac, we always get full update.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When a widget is shown we get two paint avent on Mac
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The timer interval used currently on Windows is 16 ms, but we get ticks
at every 32 ms on average, so the consistent timing is not reliable on windows.
We should use the multimedia timer instead (use 15 ms for QTimer), once
qt is able to handle events while native event loops are running.
When this is done, the ifdefs introduced in this commit should be removed.
Reviewed-by: thierry
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Here lot of views were floating around and the processEvent was not
called in the right place.
Reviewed-by:ogoffart
|
| | | |\ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Commit fc3dfc20d487cb4fd2f93bd9fa36eef85a7467a3 fixes the problem.
The unpolished items list was modified in between the iteration
which means that invokeMethod was never recall if you add an item
inside the polishEvent handler. The invokeMethod is called in addItem
only when the list is empty right before we add the item in the list.
Task-number:QTBUG-4439
Reviewed-by:TrustMe
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This patch make sure that we always start from the beginning of
the unpolished items list and we erase the first value at each iteration.
The patch also convert the list to a set that is more appropriate here.
Merge-request: 1707
Reviewed-by: Alexis Menard <alexis.menard@nokia.com>
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This fixes a weird bug when pressing the menu key on a proxy that
embed a lineedit (but the proxy don't have the focus).
At each time the key was pressed a context menu was created. When we press
the menu key, QWidgetMapper will create a context menu event that will be
sent to the QGraphicsView and will end up in QGraphicsScene.
QGraphicsScene will then try to find all items under the mouse and will
try to find any item from this list that accept this contextMenuEvent.
In our case the proxy will always accept it and therefor will always send
it to the widget that it owns and that's why we had this infinite numbers
of QMenu. In QWidget world the context menu event is always sent to the
widget that has the focus. If you checked any QWidget subclasses you'll
see that all of them assume that when they get a context menu event
everything is fine focus wise. We could have changed
QGraphicsScene::contextMenuEvent but this will breaks some existing code.
Instead we just checked that QGraphicsProxyWidget has the focus
before we actually send the contextMenuEvent to the widget it owns.
I have modified an existing auto-test to cover that. Be careful
widget->setContextMenuPolicy(Qt::ActionsContextMenu) means that you will
get no contextMenuEvent. :D. In this test i cover the standard use case
and the one with Qt::ActionsContextMenu with and without the focus on the
proxy.
Task-number:QTBUG-3787
Reviewed-by:jan-arve
|
| | | |\ \ \ \ |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
When there are only pause animations running, the timer will stop and
restart when the closest pause animation finishes. While there are only
pause animations running, there are no additional timer ticks, but
if there is at least one animation running that is not a group or a pause,
then the global animation timer will restore it's update interval.
Includes a new auto-test for the QPauseAnimation class.
Task-number: QT-941
Reviewed-by: thierry
Reviewed-by: janarve
|
| |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Due to lower performance the expected signal count was decreased for
this test.
Reviewed-by: Maurice
|
| | | | | | | |
|
| | | | | | | |
|