| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
We could sometimes have more than two paint events even before reaching
QTRY_COMPARE, thus it would fail.
The test failed on Windows.
|
|
|
|
|
|
|
|
| |
The bug was triggered by setting focus on a parent scope (which then
passes focus to the innermost scope). Subfocus was set up for the
first scope, but not the inner scopes.
Reviewed-by: TrustMe
|
| |
|
|
|
|
| |
Reviewed-by: Paul Olav Tvete
|
|
|
|
| |
Reviewed-by: Jan-Arve
|
|
|
|
| |
Reviewed-by: Jesper
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature is essential for Declarative UI, but does not add much
value for C++ developers. A FocusScope provides a stack of focused
widgets, and it ensures that the topmost item on the stack has
focus if any of the items in the stack gains focus. When the topmost
loses focus, focus is passed to the "parent" focus scope, and so on.
You can get almost the same behavior using panels (ItemIsPanel),
except panels impose other behavior, like stopping clickfocus
propagation, and stopping event propagation in general. In a QML
world you would typically use FocusScope for controlling focus
locally, and panels when you need to maintain separate focus stacks.
Reviewed-by: akennedy
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure you can't set focus on an inactive scene, allow items
with subfocus to gain focus even if added to a scene that's not
active, and finally ensure that activating a panel in an active,
but unfocused scene, gives focus to the scene.
Also added a test that checks adding normal vs. panel items to an
active vs. inactive scene, and what happens if you initially say
the item should have focus.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
|
|
| |
This line was added to fix crashes when deleting items that had
a subFocusItem pointing to a child that was already deleted. This
bug was fixed by ebb1162f54a29baeccb71d1e283146892629518f. After
this, subFocusItem is always 0 at this point.
The original change was eb3d5a73148cd7206c6b3b6672ed47b44611f745.
Reviewed-by: TrustMe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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...
Cherry-pick of commit d6b8f81a2440e7a507ecbb1becd90ef284510787 from master.
Reviewed-by: thartman
Conflicts:
tests/auto/qwidget/tst_qwidget.cpp
|
| |
|
|
|
|
| |
Reviewed-by: Trond
|
|
|
|
| |
Pointed out by Caio.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug appeared only when calling collidingItems right after setPos.
When calling setPos on a parent the sceneTransform is mark as dirty, so
when we paint the parent and its children if the scene transform of the
parent was dirty then we update all children sceneTransform. In our
case here, collidingItems call ensureTransform on one of the children
which go recursively to the top most dirty item and update the
sceneTransform. The problem is that all sibling children are not mark
their sceneTransform dirty so next paint will skip them (since the parent
is not dirty anymore).
Task-number:260711
Reviewed-by:bnilsen
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Uses the primary key from the index in the query, not the resulting
location in the modified dataset.
Task-number: 222678
|
| |
| |
| |
| |
| | |
Autotest: included
Reviewed-by: Bjørn Erik Nilsen
|
| |
| |
| |
| | |
Reviewed-by: Bjørn Erik Nilsen
|
| |
| |
| |
| | |
Reviewed-by: Bjørn Erik Nilsen
|
| |
| |
| |
| | |
Reviewed-by: TrustMe
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To allow fading between the original and the colorized version of the
pixmaps, a new strength factor is introduced, 0.0 means the filter
has no effect at all, 1.0 means full colorization.
Still missing is the non-raster implementation.
Autotest: included
Reviewed-by: Bjørn Erik Nilsen
|
| |
| |
| |
| |
| |
| |
| | |
QWS uses alien widgets too, so we need the same logic as the other
platforms.
Reviewed-by: bnilsen
|
| |
| |
| |
| | |
Reviewed-by: bnilsen
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Say hello to QGraphicsAnchor, move the spacing (and removeAnchor)
functionality over to that class.
This also opens up for a cleaner API when we add support for size
policies or min/pref/max sizes for anchors.
Also remove
- addLeftAndRightAnchors()
- addTopAndBottomAnchors()
- addAllAnchors()
in favor of
- addAnchors(itemA, itemB, Qt::Orientations)
API change discussed with Caio and Andreas.
Reviewed-by: Alexis
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Change 93ba0035f4eadfaf7217d95f18a442d418a064b8 removed truncation of
a listview item's bounding rect to the viewport as documented in the
commit log. An unwanted result was that the style option passed to the
item delegates would sometimes contain a rectangle which was larger than
the delegated area. The direct result was that a QComboBox drawn with a
style with the SH_Combobox_Popup style hint in an RTL language would
align its item text to the right edge of a rectangle which was wider
than the popup menu, and thus only part of the text would be visible.
Task-number: 260974
Reviewed-by: Olivier
|
| | |
|
|\ \
| |/
| |
| |
| |
| | |
Conflicts:
tests/auto/qhttpnetworkconnection/qhttpnetworkconnection.pro
tests/auto/qhttpnetworkreply/qhttpnetworkreply.pro
|
| |
| |
| |
| |
| |
| | |
test was not building
Reviewed-by: Trust Me
|
| | |
|
| |
| |
| |
| | |
Merging fix back into 4.5 tree
|
| |
| |
| |
| |
| |
| |
| | |
Ported this fix backwards from 4.6 to 4.5
Adds some cleanups (using QVarLengthArray), and reverting to the
initial and correct calculation (when the driver doesn't deem fit to
return SQL_NO_DATA).
|
| |
| |
| |
| | |
Reviewed-by: Marius Bugge Monsen
|
| | |
|
| |
| |
| |
| |
| |
| | |
test was not building
Reviewed-by: Trust Me
|
| | |
|
| |
| |
| |
| | |
os9-newlines.h must not contains any linebreak
|
| |\ |
|
| | |
| | |
| | |
| | | |
Reviewed-by: Trust Me
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a layoutDirection autotest, and sprinkle some of the tests
with checkReverseDirection()
Reviewed-by: Eduardo M. Fleury
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some platforms do not recalculate the Qt::WA_UnderMouse attribute when
a widget is shown underneath the mouse.
Reviewed-by: Olivier
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It is planned that this test will do something sensible in the future.
Reviewed-by: Jesper
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
qUncompress shouldn't crash when running out of memory, since it might deal
with buffers which are not under user control (same behavior as Qt 4.5).
It will however throw a std::bad_alloc exception if Qt is compiled with
exception handling.
Reviewed-by: Harald Fernengel
Reviewed-by: Ralf Engels
Reviewed-by: Lars Knoll
|
| | | |
| | | |
| | | |
| | | | |
also improved the autotests
|
| | | |
| | | |
| | | |
| | | | |
We have mousemove events but we were missing the mouse press ones.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
activeWindow documentation says: "active window is a visible
top-level window that has the keyboard input focus" and "If you want to
ensure that the window is stacked on top as well you should also call
raise(). Note that the window must be visible, otherwise activateWindow
has no effect."
What we were doing earlier was basically raise. Now we just set the
keyboard focus to underlying native window.
Task-number: 260685
Reviewed-by: Jason Barron
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The "standard" test would sometimes fail (Mac OS X)
because extra paint events could be generated, which
would cause paintNumber to be > 1. Comparing it to 1
would fail. This test should be redesigned, I think.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
no more qApp->processEvents() !
Reviewed-by: ossi
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Before this commit calling setWindowState(Qt::WindowFullScreen) on
a widget instance affected all new widget instances created after this
method.
This bug happened due to fact that window decorations i.e. statuspane
and softkeys visibility was only changed when switching to or from
fullscreen state. In the reported bug it happened that second widget
was initially in Qt::WindowNoState and it was changed to Maximized.
Since window decorations are global not window specific at the moment,
the default decoration visibility for second window is the one to which
previous window has set them. In this case previous window was in
fullscreen and that's why the decorations were visible also for
second maximized window.
Probably the right fix would be to change the decoration to window
specific but that is quite a big change and for now the bug is fixed
with this commit.
Autotest: Excluding new test case, same results before and after.
Task-number: 261048
Reviewed-by: Jason Barron
|