| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The server color layout test was a bit to harsh, since it excluded
16 bit X11 servers with RGB layout.
Task-number: 259846
Reviewed-by: Gunnar
|
|
|
|
|
|
|
|
|
|
|
| |
Problem introduced by 7661126bc86ed105c02fd9b084ac5a91f12f10c4, which
introduced always rounding up when converting the rectangle's
coordinates to integers. This would e.g. cause off-by-one errors for the
cursor in QTextDocument. Some code paths depended on the ceiling of the
coordinates, and these have been reverted.
Task-number: 257914
Reviewed-by: Samuel
|
|
|
|
|
|
|
|
| |
We integrate QMenu into the native menu system. Thus it doesn't make
sense to click at position (5,5) or so. We have the windowsmobile
auto test for this.
Reviewed-by: thartman
|
|
|
|
| |
Reviewed-by: thartman
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression when computing the clip path for a
QGraphicsWidget that clip its children to its shape. The clip path cache
use the bounding rect which has a null width and height the very first
time on a QGraphicsWidget. This might happen as well for any item that
have a null width and height (e.g. QGraphicsRectItem before you set the
rect). We should do better in mainline by refactoring this clip path
cache and calling it in prepareGeometryChange which should be called
when you update the shape and the boundingRect of the item. Do we
really need also in 4.6/mainline the clip path as it is now? This should
be investigate also. The auto-test cover the problem so we can use it
after for refactoring the cached clip path.
Task-number: 257232
Reviewed-by: andreas
Reviewed-by: bnilsen
|
|
|
|
|
|
| |
Fixes https://bugs.webkit.org/show_bug.cgi?id=28016
Reviewed-by: andreas
|
|
|
|
|
|
| |
Whitespaces in identifiers now past autotests
Reviewed-by:Bill King
|
|
|
|
|
|
| |
test was broken
Reviewed-by:Bill King
|
|\ |
|
| |
| |
| |
| |
| |
| | |
We run out of memory on the test system in this test.
Reviewed-by: mauricek
|
| |
| |
| |
| |
| |
| |
| | |
We must not retrieve the initial window geometry for
WA_DontShowOnScreen widgets with GetClientRect.
Reviewed-by: thartman
|
|/
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
| |
Nowadays every Windows mobile application has a menu (for correct soft
key support). That's why we need a new screen shot.
Reviewed-by: thartman
|
| |
|
|
|
|
|
|
| |
The screenshots in the QRC were taken on the WM5 emulator.
Reviewed-by: thartman
|
|
|
|
| |
Reviewed-by: thartman
|
| |
|
| |
|
|
|
|
|
|
|
| |
We could do it or we couldn't. It's simply a judgement call and I think
the comments in the task are a good argument for NOT doing it.
Task-number: 227875
|
|
|
|
|
|
|
|
|
|
|
|
| |
The style was assuming that the combo box is painted at (0,0). This is
not the case when the painting is done in the delegate of an item view.
The offset of the rect is now taken into account to paint the style.
HIRect has been replaced by QRect when it make sense.
Task-number: 00026815
Reviewed-by: Richard Moe Gustavsen
|
|
|
|
|
|
|
|
| |
The function hitTestComplexControl() of the mac style returned
SC_ComboBoxArrow when the point is not over an element of the widget.
Task-number: 252857
Reviewed-by: Richard Moe Gustavsen
|
|
|
|
|
|
|
|
|
| |
A QPushButton with a height if (say) three pixels would cause
HIThemeGetButtonContentBounds ot return a rect with dimentions
{int_min, int_min, 0, 0}. Detect that case and return the button
rect instead.
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
| |
The magic number 22 was based on windows sized icons, a size of 16
should be correct for mac
Task-number: 259289
Reviewed-by: NRC
|
|
|
|
|
|
|
|
| |
That should fix compilation on platforms that do not have xinput
headers installed.
Reviewed-by: Thiago Macieira
(cherry picked from commit 0a13188468997d6c3253db5b29f05a119945f131)
|
|
|
|
| |
Reviewed-by: Leo
|
|
|
|
|
| |
Reviewed-By: mauricek
Reviewed-By: thartman
|
|
|
|
|
|
|
|
| |
This test created a widget at position (0,0) and grabbed the screen.
That's a bad idea on Windows mobile because the upper task bar will
cover the widget.
Reviewed-by: thartman
|
|
|
|
|
|
|
|
| |
The widget must be created before calling QInputContext::setFocusWidget.
Otherwise we run into an assertion. Yes, this only occurs in debug
configuration but its still annoying...
Reviewed-by: thartman
|
|
|
|
| |
Reviewed-by: TrustMe
|
|
|
|
|
|
|
| |
Code is adapted from QCommonStyle which handles this case for other
styles.
Reviewed-by: thartman
|
|
|
|
|
|
|
|
| |
This function was too strict. It returned 0 if the property wasn't of
type QVariant::Double. Now it tests for QMetaType::Float too.
Reviewed-by: kh1
Reviewed-by: mauricek
|
|
|
|
|
|
|
|
| |
Widgets with the WA_DontShowOnScreen attribute must not have a window
decoration.
Autotest: tst_QWidget::initialPosForDontShowOnScreenWidgets
Reviewed-by: thartman
|
|
|
|
|
| |
Make sure the testcase and directory name are the same
(excluding `tst_').
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
| |
This reverts commit 6844dea0cb583a86bc72e7f008720ab76deef040.
added to wrong branch. should be in 4.6 but this was added to 4.5
|
|
|
|
|
|
|
|
|
|
|
| |
calendar popup
A frame was always drawn around the QDateTimeEdit editor if a popup
calendar had been set. QStyleOptionsComboBox options are being set in
paintEvent and initialised from the properties of QStyleOptionsSpinBox but
were missing the frame bool property. Now, if the user sets a frame on the
QDateTimeEdit, this property will be consistent with setFrame() property
of the QDateTimeEdit widget.
|
|
|
|
| |
Task-number: 259482
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
| |
After the coverity fix, the proper code path executed, which failed to
enquote the date field properly, so this fix fixes that issue.
|
|
|
|
| |
Found by coverity.
|
| |
|
|
|
|
| |
Genarated->generated
|