| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| | |
QWidget::repaint() is not immediate on the Mac; it has to go through
the event loop.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QGLWidget does not support partial updates unless the context is
single buffered and auto-fill background is disabled. The problem
was that QPaintEvent::region() returned the requested update region
without taking into account the limitation of QGLWidget. If QGLWidget
doesn't support partial updates, it means everything has to be updated,
and QPaintEvent::region() must return the whole widget rect.
Auto test included.
Task-number: 241785
Reviewed-by: Trond
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If you insert a new pixmap in the cache with a key that was already in
the cache then we remove the old pixmap and add the new one. This avoid
to fill the memory with garbage even if the cache has a protection to
avoid running out of memory. This was discovered with QraphicsView
and its cache. We don't need to keep old cached pixmaps for an item.
Task-number: KDE
Reviewed-by: Trond
|
| | |
| |
| |
| |
| |
| |
| |
| | |
(This was only working if the QLabel had a QTextControl)
Also rename the QStyleSheetStyle::focusPalette to ...::styleSheetPalette
Reviewed-by: Jens Bache-Wiig
|
| | |
| |
| |
| | |
and add some missing images required for a previous test
|
| | |
| |
| |
| |
| |
| |
| | |
when the filter change
Task-Number: relates to 251296
Reviewed-by: Marius Bugge Monsen
|
| | |
| |
| |
| | |
also added autotests
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
an untransformed painter
When passing a painter to QWidget::render, we use the
painter->paintEngine()->systemClip() as the "system viewport",
i.e. all painting triggered by render() should be limited to
this area. The only way to achieve this is by always ensuring the
system clip is clipped to the same area (systemClip &= systemViewport).
The problem however, was that we only did this for transformed
painters. We must of course always do it when there's a systemViewport
set, regardless of whether the painter is transformed or not.
Auto test included.
Task-number: 248852
Reviewed-by: Trond
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
written, IANA hadn't assigned one.
Requested/spotted by Nokia i18n team.
Task-number: 251790
Reviewed-by: Brad
Reviewed-by: Denis
AutoTest: In this submit.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Requested/spotted by Nokia i18n team/Darpan.
Task-number: 252102
Reviewed-by: Denis
AutoTest: In this submit.
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts (version number change in 4.5):
src/corelib/global/qglobal.h
src/qbase.pri
tools/qdoc3/test/assistant.qdocconf
tools/qdoc3/test/designer.qdocconf
tools/qdoc3/test/linguist.qdocconf
tools/qdoc3/test/qmake.qdocconf
tools/qdoc3/test/qt-build-docs.qdocconf
tools/qdoc3/test/qt.qdocconf
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch complete the two others made by Kim :
- 6c2dd295b2ca2f9125fe072d035a3784ce748718
- 003223dcfc1fa884b82085db19d4c4056bf6eaa0
It fix the stops if the gradient link to another gradient below.
Task-number: KDE
Reviewed-by: Kim
Reviewed-by: Samuel
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While working on layering in Graphics View I stumbled over this bug. The
QGraphicsItem::childrenBoundingRect() function had an accumulating error
caused by recursive adding of rectangles that individually were mapped to
the local parent using QGraphicsItem::mapRectToParent() /
QTransform::mapRect. This caused the brect to be way too large for items
with children that are rotated (fex, alternating 45 and -45 degrees).
The new version should be just as fast, but with no loss of precision.
Reviewed-by: bnilsen
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
about the only error case for a PeekNamedPipe() which does not actually
want to read anything is some kind of disconnect. so ignore the error
code and just handle the error as a close.
Task-number: 247144
Reviewed-by: thiago
|
| | | |
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
tests/auto/qaction/tst_qaction.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Copy constructor and assignment operator lose data: pointer to content
and the length of content also need to be copied over.
QByteArrayMatcher::pattern() would return a null byte array if instance
was initialized with c-string.
Changed default constructor to explicitly initialize pattern length to
zero.
The bug in the assignment operator is a regression against 4.4.3.
Task-number: 251958
Reviewed-by: MariusSO
Reviewed-by: paul
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 031adeaf42ddaef8d01338f6c59ba97170be5d53.
The patch had some unforeseen side-effects for Creator.
It may also affect other existing applications in a similar way.
For now, this behavior (eating key sequences for disabled shortcuts)
should be achieved using a local workaround in creator.
Reviewed-by: mariusSO
Task-number: 251246
|
| |\ \
| |/
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/global/qfeatures.h
src/gui/painting/qtransform.cpp
util/scripts/make_qfeatures_dot_h
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We have code that assumes that m33 = 1 if the type is TxScale. Instead
of changing all that code it's better to just return TxProject as type
when m33 is different from 1.
Reviewed-by: Simon Hausmann
|
| | |
| |
| |
| |
| |
| | |
We need to check if the engine is null before we do the thread test.
Reviewed-by: Thiago
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem is QUrl == operator is case sensitive. On Windows we don't
want double entries for C:\dev or c:\dev so i convert the url in lower
case and compare them (on Windows only) to avoid duplicate entries.
Task-number:226483
Reviewed-by:jasplin
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The reason it failed was that we always expected the height property
of the BMP header to be double the height of the icon. The
kde_favicon.ico did not fulfill this requirement. We can fix that by
simply reading from the ICONDIR entry instead, since that has always
the correct height.
Task-number: 229829
Reviewed-by: alexis
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/graphicsview/qgraphicsitem.cpp
tools/qdoc3/test/assistant.qdocconf
tools/qdoc3/test/designer.qdocconf
tools/qdoc3/test/linguist.qdocconf
tools/qdoc3/test/qmake.qdocconf
tools/qdoc3/test/qt-build-docs.qdocconf
tools/qdoc3/test/qt.qdocconf
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a bug in 4.5.0 where cached items that call update() after
they have been moved or transformed failed to get a call to paint(),
so the last cache image was used to draw. The easiest way to reproduce
this bug is in the Elastic Nodes example. If you press, wait, then
release, the nodes will consistently move to sunken state, then back
to normal state. But if you click quickly while moving the mouse, the
nodes will stay sunken.
The bug was that the item was marked as dirty as a result of being moved,
and when the mouse button was released, the node item's call to update()
was discarded, as the item was "already dirty".
The fix is to allow invalidation of the cache even if the item is
marked as dirty.
Reviewed-by: bnilsen
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we were calling two times itemChange on the parent to give
QGraphicsItem::ItemChildAddedChange. We don't need that. One is enough.
BT : yes
Task-number: BT
Reviewed-by: Andreas
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We can't remove an item in the sidebar if the bookmark is not valid
(i.e. link to a non existing directory). ItemViews doesn't allow you
to have disabled items and to select them at the same time, so i have
implemented a delegate that paint in gray if the bookmark is invalid.
So you can click on it and delete it.
Task-number: 251341
Reviewed-by: jasplin
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the bookmark in the sidebar has an hidden parent and the QFileDialog
is set up to not show hidden files, then clicking on the bookmark move
the current dir to root (like if the bookmark was invalid) instead of
entering in the dir. The fix was to fetch the parent dir and the
bookmark dir when the user select it in the sidebar.
Task-number: 251321
Reviewed-by: jasplin
|
| | | |
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
tests/auto/qaction/tst_qaction.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A disabled QShortcut should eat its key sequence even for complex
sequences like "Ctrl-E 1". For example, a line edit with such a
shortcut should not display 1 after typing "Ctrl-E" and then "1".
The patch achieves this essentially by moving more of the
decision making (of whether to eat the key secuence) from
shortcutmap.cpp to qhortcut.cpp.
Moreover, an invisible QAction should not eat any of its key sequences
(primary nor alternates). In the example above, the line edit
would display 1 when typing this sequence for an invisible action.
The patch achieves this by temporarily unregistering all of the
action's shortcuts while the action is invisible.
Reviewed-by: mariusSO
Task-number: 251246
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We were calling the provider with invalid path, with the default one it
fallback to all standard icons but with a custom one we call a public
method with an invalid QFileInfo. It was happening on windows only
for the My Drives view because in that case the parent path is null, my
Drives is a logical view.
Task-number: 251295
Reviewed-by: jasplin
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change fixes a few bugs and adds autotests for QGraphicsProxyWidget
and QGraphicsWidget's window flag handling. The former behavior has been
that you must set window flags on QGraphicsProxyWidget explicitly after
calling proxy->setWidget(); otherwise both the flags from the embedded
widget and the proxy would be partially ignored. Example:
QLineEdit *edit = new QLineEdit(0, Qt::Window); // that's the default
scene.addWidget(edit, Qt::Window); // proxy still has no window decos
proxy->setWindowFlags(Qt::Window); // now it got decorations :-/
QGraphicsWidget's window flags are immune to reparenting, and are always
polished with the necessary hints regardless of whether you set the
flags during construction time or later. This is a feature QGraphicsWidget
can provide because it allows toplevel widgets (without parents) to be
normal widgets (i.e., non-windows).
So the new behavior of QGraphicsProxyWidget is to respect its own window
flags and ignore those of the embedded widget, regardless of what flags
the embedded widget has when it's embedded. When QWidget auto-embeds
child windows (file dialogs, popups, etc), it passes the correct window
flags to the QGraphicsProxyWidget to ensure that the right flags are set.
Task-number: 251407
Reviewed-by: Joao
|
| | | |
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
src/gui/itemviews/qheaderview_p.h
|
| | | |
|
| | |
| |
| |
| |
| | |
heh, it was perfectly safe to remove the QT_VERSION ifdefs, but
QT_VERISON was another matter...
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem is in QTabBar which emits the currentChanged signal
before accessing its own internal data. As we react to that signal by
possibly removing/adding tabs, it can cause a assertion failure.
Task-number: 251184
Reviewed-by: ogoffart
|
| | |
| |
| |
| |
| |
| |
| | |
QHeaderView can sometimes display holes when using default row height
Task-number: 248050
Reviewed-by: ogoffart
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was that if you had child widgets of a popup, only child
widgets that had hasMouseTracking() == true received the ToolTip
event. This was because in order for a widget to receive a ToolTip,
it relied on the MouseMove event.
It still relies on the MouseMove event, but the problem with the
previous code was that it did not even *try* to deliver the MouseMove
event to the widget that did not have mousetracking. And it was
the code that "tried" to deliver (QApplication::notify()) the event
that also was responsible of finding which widget it should get the
tooltip from. Unfortunately the previous code did not even enter
QApplication::notify() because of that early cut-off.
The result was that the event was propagated up to the parent widget
(which was the popup) and consumed by the popup. (Nothing would happen
unless the popup itself had a tooltip). This is also how
translateMouseEvent() is implemented in qapplication_x11.cpp.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The QGraphicsView::mapToScene(QRect) function assumes that QRect and
QRectF share semantics for ::bottomRight(). However, since QRect follows
Qt 3 semantics (the rect is based on viewport pixels and (0,0,1,1) is
equivalent to one pixel, topleft = bottomright), this function gives
unexpected behavior: map(0,0,1,1) gives you an empty polygon! To work
around this, users of the function need to adjust their rectangles
with (0,0,1,1) to get the correct behavior, matching what QRectF does.
QRectF(0,0,1,1).bottomRight() == QPointF(1,1)
QRect(0,0,1,1).bottomRight() == QPoint(0,0)
Reviewed-by: TrustMe
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
tests/auto/qpainterpath/tst_qpainterpath.cpp
|
| | |
| |
| |
| |
| |
| |
| | |
This test has always been wrong/confusing. Fix it to work, and make sense.
Task-number: 250026
Revby: Lincoln Ramsay
|
