summaryrefslogtreecommitdiffstats
path: root/src/gui/graphicsview
Commit message (Collapse)AuthorAgeFilesLines
* Merge qt-team-widgets/4.6 into origin/4.6Olivier Goffart2009-10-133-6/+9
|\
| * Merge commit '8df79a473e1a7e5c79b9b10827985bf3e9501002' into 4.6Alexis Menard2009-10-125-5/+21
| |\
| * \ Merge branch '4.6' of git@scm.dev.nokia.troll.no:qt/qt into 4.6Alexis Menard2009-10-092-27/+32
| |\ \
| * | | Fixed a potential crash in QGraphicsScenePrivate::_q_polishItems()J-P Nurmi2009-10-092-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | Fix context menu and menu key in QGraphicsView.Alexis Menard2009-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | Doc: Gesture API documentation review.David Boddie2009-10-121-2/+1
| | | | | | | | | | | | | | | | Reviewed-by: Trust Me
* | | | Added documentation for the Gesture API.Denis Dzyubenko2009-10-121-2/+9
| |_|/ |/| | | | | | | | Reviewed-by: trustme
* | | A new implementation of the Gesture API.Denis Dzyubenko2009-10-095-5/+21
| |/ |/| | | | | | | | | | | Implemented gestures using gesture events and separate QGesture/QGestureRecognizer classes. Reviewed-by: trustme
* | Rename identifyNonFloatItems -> identifyFloatItems.Jan-Arve Sæther2009-10-082-8/+8
| | | | | | | | We changed the behaviour of that, so the name should reflect that.
* | Merge branch 'openbossa-expanding' into 4.6Jan-Arve Sæther2009-10-082-21/+26
|\ \ | |/ |/|
| * Store the floating items instead of the non-floating items.Jan-Arve Sæther2009-10-072-21/+26
| | | | | | | | | | Makes the code a bit easier to read and speeds up setItemsGeometries() in the normal use-case.
* | Using const refs for passing qreal will make Qt slower on some systems.Jan-Arve Sæther2009-10-071-2/+2
|/ | | | | For instance, if sizeof(qreal) == 4 (for instance on ARM) the stack size needed will be the same, so it will just add an extra indirection.
* Cosmetic fixes to the previous patches.Jan-Arve Sæther2009-10-074-38/+40
| | | | | | There is only one change in the actual code here, and it simply removes an unnecessary initialization of hasSize in the ctors of the composite anchors.
* QGraphicsAnchorLayoutPrivate: Fixing initial geometry values for new layout ↵Jesus Sanchez-Palencia2009-10-061-12/+25
| | | | | | | | | | | items Now every item starts with its geometry on ((0,0), preferredSize()). By doing this we guarantee that every item will have a known initial value, which can be specially useful on float cases for instance. Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org> Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
* QGraphicsAnchorLayoutPrivate: Handling floating items as an invalid layout ↵Jesus Sanchez-Palencia2009-10-062-1/+53
| | | | | | | | | | | situation We make use of the anchor visited on findPaths() to keep track of how many items are visited when walking on the graph. We can use this information of how many items are reachable (non-float) in order to check if we have floating items (not reachable from any graph vertex). If so, we have a situation not supported by now. Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org> Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
* QGraphicsAnchorLayout: Fix creation of internal layout anchorsEduardo M. Fleury2009-10-061-62/+83
| | | | | | | | | | | | Since the AnchorData cleanup commit (c974aca8) all anchor initialization is being done by refreshSizeHints. However that method was not able to properly initialize the internal layout anchors. This commit refactors that method both to add the functionality and improve readability. Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org> Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
* QGraphicsAnchorLayout: Add support for expanding SizePolicy with simplificationCaio Marcelo de Oliveira Filho2009-10-062-27/+36
| | | | | | | | | | | | | Updating "refreshSizeHints" and "updateChildrenSizes" methods for standard, parallel and sequential anchors, in order to support the expanding SizePolicy flag. This adds the logic required to calculate equivalent expected/nominal expanding size (AnchorData::expSize) as well as the logic to propagate the effective size when in the expanding state (AnchorData::sizeAtExpected). Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
* QSimplex: Remove overly conservative assertionEduardo M. Fleury2009-10-062-19/+31
| | | | | | | | | | | | | This assertion started failing after the addition of expanding state. After some investigation we felt that the assertion itself was too strong and would fail in some valid cases. The new assertion is formally right as it tests whether the simplex solver was able to satisfy the simplex constraints, _exactly_ what it is expected to do. Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org> Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
* QGraphicsAnchorLayout: Update solveExpanding to handle simplified graphsEduardo M. Fleury2009-10-061-12/+72
| | | | | | | | | | | | | | | | | | | | | | | The previous implementation of solveExpanding would assume that anchors were either completely expanding (would grow to their sizeAtMaximum) or non-expanding (would try to remain at their sizeAtPreferred). What happens however is that with simplification enabled, we may have anchors that are "partially" expanding. An example is a sequential anchor that groups together two leaf anchors where only one of them is expanding. In this case, the expected size of that group anchor would be the sum of the max size of the expanding child plus the preferred size of the non-expanding child. To handle the above case we added the "expSize" variable. It holds the expected value at Expanding for each anchor. Based on this, and the already calculated values of sizeAtMaximum and sizeAtPreferred, the solver calculates the actual sizeAtExpanding for them. Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org> Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org>
* QGraphicsAnchorLayout: avoid code duplication when initializing complex anchorsCaio Marcelo de Oliveira Filho2009-10-062-52/+54
| | | | | | | | | | | | | Now we can use refreshSizeHints_helper() to initialize complex anchors (parallel and sequential). This avoids duplication of code in the function simplifySequentialChunk(). This commit also 'disable' ExpandFlag temporarily, stabilizing the tests for the simplification. The next commit should re-enable it implementing the necessary code for simplification as well. Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
* QGraphicsAnchorLayout: cleaning up AnchorDataCaio Marcelo de Oliveira Filho2009-10-062-83/+59
| | | | | | | | | | | | | | | | Use just one constructor for AnchorData and tweak the struct when necessary. Also use the function refreshSizeHints() for Normal anchors to get the item information instead of passing to the constructor. This has the advantage that we don't need to replicate the code for checking and updating the size hint and size policies. Note that the code before only considered the size policies after the first refreshSizeHints() -- which we know will be called after the simplification, so the assumption seems to be correct, but we don't depend on that anymore.. Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
* QGraphicsAnchorLayout: Enabling Simplex support for Expanding size policyEduardo M. Fleury2009-10-062-11/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support the expanding size policy we had to change the way the setup process work. Previously we used to calculate three key-frames using the simplex solver: - sizeAtMinimum: the value an anchor should be in when the layout is at its minimum size. Calculated using simplex solver to minimize the layout size. - sizeAtPreferred: the value an anchor should be in when the layout is at its preferred size. Calculated using simplex solver to minimize the deviation from the items preferred sizes. - sizeAtMaximum: the value an anchor should be in when the layout is at its maximum size. Calculated using simplex solver to maximize the layout size. That worked fine but didn't diferentiate standard items from the "expanding" ones. In other words, all items would grow from their sizeAtPreferred to their sizeAtMaximum at the same rate. To support the idea of "expanding" items, ie. items that should grow faster than the others, we added a fourth state, between preferred and maximum. Now we have the following interpolation order: sizeAtMinimum -> sizeAtPreferred -> sizeAtExpanding -> sizeAtMaximum. The definition of the "expanding" state is that all "expanding" items should have grown all the way to their "sizeAtMaximum" values whereas non expanding items should have kept their preferred sizes. The only exception is that non-expanding items are allowed to grow if that is necessary to allow the "expanding" items to reach their sizeAtMaximum. So, the visual result is that if the layout is resized from its preferred size to its maximum size, the expanding items will grow first and then, in a second phase, the other items will grow. This commit adds QGALPrivate::solveExpanding() and calls it from calculateGraphs(). Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org> Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
* QGraphicsAnchorLayout: Add data structures for Expanding size policyEduardo M. Fleury2009-10-062-13/+51
| | | | | | | | | | Adding required members for the upcoming support of the QSizePolicy::Expand flag. In this state, running with simplification will probably not work. Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org> Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
* Fix the pad navigator demo.Alexis Menard2009-10-061-1/+1
| | | | | | | | | | | | QGraphicsWidget used to called setPosHelper where all the logic was. But since the new flag itemSendsGeometryChanges some part of the code inside setPosHelper move back to setPos. QGraphicsWidget was not updated after this change. It doesn't matter as it is but for QGraphicsProxyWidget which activate the flag itemSendsGeometryChanges it matters. ItemChange was never called so the proxy was never really moved. Task-number:QT-672 Reviewed-by:andreas
* Doc fix.Alexis Menard2009-10-051-0/+30
| | | | Reviewed-by:TrustMe
* Make QEventTransition works with QGraphicsObject.Alexis Menard2009-10-052-7/+11
| | | | | | | | | | | QStateMachine framework installs QObject event filters to catch events in order to triggers the proper transition. But installing a QObject event filter on a QGraphicsObject gives nothing because QGraphicsView events filters works differently. In order to make this works we now post events using QApplication::postEvent in addition to the QGraphicsView events. Reviewed-by:andreas
* Doc: silence more qdoc warnings.Volker Hilsheimer2009-10-032-14/+7
| | | | | Mark QGraphicsAnchor::unsetSpacing as reset function of the spacing property.
* Doc: add \since 4.6 to new QGraphicsItem::PanelModality enum.Volker Hilsheimer2009-10-031-0/+1
|
* Update documentation for sorting / stacking order in Graphics View.Andreas Aardal Hanssen2009-10-023-164/+202
| | | | | | | | | | Remove all references to "elevation" and how items are sorted by their "z order". Now use "stacking order" and only refer to "z-value" when discussing sibling order. Move almost all sorting docs from the QGraphicsItem::setZValue() function to a general overview section in QGraphicsItem's class documentation. Reviewed-by: David Boddie
* qdoc: Added a missing "/" in a "<h2>".Martin Smith2009-10-011-105/+107
|
* Add support for modality to QGraphicsItem panels.Bradley T. Hughes2009-10-015-21/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This add QGraphicsItem::setPanelModality(), panelModality(), isBlockedByModalPanel() and the QGraphicsItem::PanelModality enum (enumerators are either SceneModal, PanelModal, or NonModal, which mirror Qt::ApplicationModal, Qt::WindowModal, and Qt::NonModal). Reviewed-by: ahanssen Squashed commit of the following: commit a980a1b9c2972c676f3a70e8577d4eace54a25b3 Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Wed Sep 30 14:42:01 2009 +0200 Fix tst_QGraphicsItem::modality_hover() test failures As pointed out by Andreas, QGraphicsScenePrivate::dispatchHoverEvent() already has all the logic needed to correctly dispatch the hover events when changing modality. All we need to do is store the last known mouse position, and call dispatchHoverEvent() when entering, changing, and leaving the modal state. commit ba41633c96ece8da3a8bbf9c7491c15b14f83f76 Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Wed Sep 30 14:40:59 2009 +0200 Fix tst_QGraphicsItem::mixedModality() failure When changing modality from SceneModal to PanelModal, we may need to send WindowUnblocked events in addition to the WindowBlocked events. commit d1076e315de10b1b2fb7617ebaee552c14e49c8b Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Wed Sep 30 14:33:21 2009 +0200 Update the expected events counts in tst_QGraphicsItem::modality_hover() HoverEnter and HoverMove always come in pairs, and should do so when entering or leaving modality as well. This means though that changing modality can cause spurious HoverMove events (as seen in this test). commit a29b098e4c391651ef61dd4714a66b22654e4628 Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Wed Sep 30 14:20:25 2009 +0200 Update tst_QGraphicsItem::mixedModality() to do more detailed checking The test looks for unwanted WindowBlocked/WindowUnblocked events now, making it easier to spot where the failure comes from. commit c1ae96126ed01d0e662bddf38ff161e50a804b1c Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Tue Sep 29 12:17:17 2009 +0200 Documentation for QGraphicsItem::PanelModality Document the behavior of the QGraphicsItem::NonModal, PanelModal, and SceneModal enumerators. Corrected a qdoc error in the isBlockedByModalPanel() documentation commit 02fec999e660180ff65bbbf79c8085e582879ed1 Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Thu Sep 17 10:31:44 2009 +0200 Add bool QGraphicsItem::isBlockedByModalPanel() This function can be used to figure out 1) if an item is modally shadowed and 2) which panel is blocking the item in question. This will make it possible to implement window-manager like behavior of activating/highlighting/animating modal panels when the user tries to interact with a blocked item (this will most likely need to be done by reimplementing QGraphicsScene::event()). commit eab9a975dcd71b68135325d479374108bd7f3b2a Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Wed Sep 16 14:38:55 2009 +0200 Block key events to the focus item if it is blocked by a modal panel. We don't want the event to propagate either, just stop propagating once we reach an item that is blocked. commit 038b61a10bb837b353f988cb0d1665dd53656cdb Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Tue Sep 15 12:40:27 2009 +0200 Add a test for click-to-focus behavior in the presence of modality Clicking on a widget should neither give it focus nor set it as the sub-focus item. commit 3bb3662556efe8d76af5a56e65b1df7a9f4b476a Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Tue Sep 8 09:08:42 2009 +0200 Newly blocked QGraphicsItem panels should lose implicit grabs when modality is enabled. If an item has an implicit grab when blocked by a modal panel, this grab is lost and no mouse events are sent until the mouse is released and re- commit 3be51be3da36e782a5a1f282c552064d5d490a71 Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Thu Sep 3 13:39:14 2009 +0200 Support changing modality from PanelModal to SceneModal or vice-versa Don't leave modality first, and then re-enter... this sends unnecessary events. commit bb0aea559ba01a8bbb03c0370a247ab902f561f5 Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Wed Sep 2 16:58:23 2009 +0200 Fix hover event delivery in the presence of modal panels Panels that are modally shadowed should not get hover events. When entering and leaving the modal state, GraphicsSceneHoverEnter and GraphicsSceneHoverLeave event should be send to the widgets that become or are no longer blocked. Auto-test included. commit cad00b1d9da19565e2d7ea2d30d37eb45005b5ae Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Wed Sep 2 10:45:20 2009 +0200 Fix tst_QGraphicsItem::modality_hover() test Don't send hover events to items that are modally shadowed. commit ae15df331901110e19eb2037f37ff7f84cd7cd16 Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Wed Sep 2 10:44:14 2009 +0200 Enable the ItemIsPanel flag in the modality_hover() test Otherwise the modality settings are ignored. commit 1580f43c8feabc3a2bf9c1450e1a8916e8940a4c Author: Andreas Aardal Hanssen <andreas.aardal.hanssen@nokia.com> Date: Fri Aug 28 15:20:37 2009 +0200 More work on QGraphicsItem::PanelModality. Added many tests. commit ed2064ad2ec8bc06d62cf1e931b973d5d92c0563 Author: Bradley T. Hughes <bradley.hughes@nokia.com> Date: Thu Aug 27 13:45:11 2009 +0200 Add support for modality to QGraphicsItem panels. This add QGraphicsItem::setPanelModality() and the QGraphicsItem::PanelModality enum (enumerators are either SceneModal, PanelModal, or NonModal, which mirror Qt::ApplicationModal, Qt::WindowModal, and Qt::NonModal). Reviewed-by: ahanssen
* Merge branch '4.5' into 4.6Thiago Macieira2009-09-291-7/+4
|\ | | | | | | | | | | | | | | Conflicts: doc/src/platform-notes.qdoc src/3rdparty/webkit/WebKit/qt/Api/qwebpluginfactory.cpp src/gui/graphicsview/qgraphicsitem.cpp tests/auto/qgraphicsitem/tst_qgraphicsitem.cpp
| * QGraphicsItem: cached embedded widget item is not repainted when widget is ↵Andreas Aardal Hanssen2009-09-291-16/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | updated When calling QGraphicsItem::update() on a cached item, the cache is meant to be invalidated. In the reported bug, the user had a fixed scene rect set for his scene, and removing an item caused the entire scene to be updated (marked as "all needs to be updated"). In this case, calling update() on the cached item did not cause the item's cache to be invalidated. The item's new appearance didn't show up until the next invalidation, which was the same call to update(), but this time without a preceeding full scene update. The fix is to always invalidate the cache, regardless. But only schedule a repaint of the item in some cases (e.g., in this case the whole scene was marked for update, in which case it's unnessary for this one item to schedule a repaint of itself). It's worth noting that in 4.6, removing an item be delete does not cause the whole scene to be updated, and because of that this error was not exposed. It's there nevertheless. Reviewed-by: bnilsen
| * QGraphicsItem with parent flag ItemClipsChildrenToShape not visibleAndreas Aardal Hanssen2009-09-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regression against Qt 4.4. Children of items with ItemClipsChildrenToShape would only be discovered if the view's expose region contained the outer bounding rect of all items, _if_ there was at least one item in the scene that enabled ItemIgnoresTransformations. The reason for this bug is that the presence of an untransformable item causes the item lookups to go through a different path (QGraphicsViewPrivate::itemsInArea()). This function had the bug that it didn't correctly discover children of clip-items. Because of this, in the provided test case you could "work around" the bug by either removing the clip flag, or the transformation flag. Task-number: QTBUG-4151 Reviewed-by: Alexis
* | After some discussion we decided to remove hasConflicts() from the API.Jan-Arve Sæther2009-09-294-14/+13
| | | | | | | | | | | | | | | | hasConflicts() does only make sense for a tool/editor of the layout, and how this function would help the tool is only guesswork at the moment. We keep the private API though, in order to let the autotests we inherited from Orbit pass.
* | Add missing docs for QGraphicsAnchorJan-Arve Sæther2009-09-291-0/+18
| |
* | Fix some docs to follow the Qt style. (remove asterisks, proper indenting)Jan-Arve Sæther2009-09-291-44/+44
| | | | | | | | Note that this does *not* change the content of the docs.
* | Dont generate public docs for QSimplex.Jan-Arve Sæther2009-09-291-0/+4
| |
* | doc: add some more \since 4.6 tagsVolker Hilsheimer2009-09-281-0/+2
| |
* | Use qDebug() instead of printf() when dumping the simplex matrix.Jan-Arve Sæther2009-09-251-12/+10
| | | | | | | | | | | | printf() does not work very well on windows, since it will not send the output to OutputDebugString(). This allows us to catch the output even if the program is configured without "CONFIG += console".
* | QGraphicsAnchorLayout: Fix bug where simplex would return wrong resultsEduardo M. Fleury2009-09-251-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jan-Arve found a bug where QSimplex would return bad results in some tight situations. The problem was triggered randomly but the chances of appearance were higher in problems with only one feasible solution, ie. problems what were in the boundary of feasibility. The QSimplex solver implements a two-phase simplex solver, the first phase is responsible for finding a _feasible_ solution for the problem (not the best one). The second phase starts with the basic feasible solution (just found) and changes until one that is _optimal_ is found. To implement that solution we need to add artificial variables to the original problem, before phase 1, and remove them, before starting phase 2. Unfortunately though, there was some randomness in the criteria used by the solver that would sometimes cause the removal of a good variable instead of an artificial one, between the phases. With one good variable missing, the solver would also miss an important restriction, without such, it would push the objective function too far, thus returning a "wrong" result. This commit adds a tie-breaker condition to the pivot row logic to ensure the artificial variables are removed before the "good" ones. Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org> Reviewed-by: Artur Duque de Souza <artur.souza@openbossa.org>
* | QSimplex: Add class and methods documentationEduardo M. Fleury2009-09-251-5/+108
| | | | | | | | | | | | | | | | | | | | This private class is used by QGraphicsAnchorLayout as the linear programming solver engine. This method adds documentation to implementation, method and classes. Signed-off-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org> Reviewed-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
* | QGraphicsAnchorLayoutPrivate: Avoiding graph simplification on empty layoutsJesus Sanchez-Palencia2009-09-251-1/+1
| | | | | | | | | | Signed-off-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org> Reviewed-by: Eduardo M. Fleury <eduardo.fleury@openbossa.org>
* | Removed unused parameter from graphics scene index internal functionLeonardo Sobral Cunha2009-09-252-5/+6
| | | | | | | | Reviewed-by: trustme
* | Add QGraphicsItem::stackBefore(), and fix Z ordering bugs.Andreas Aardal Hanssen2009-09-255-5/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we changed the sibling stacking order to be defined (4.5) instead of undefined (4.2, 4.3, 4.4), the need to control this stacking order arose. Before we could just say the order was random, but stable, and the only way people could rely on order was to set Z. Now, when the default order is defined as "insertion order", people start relying on this order, and incidentally they want more control. In QML, the need to have insertion order semantics is very evident as the order you define the elements in QML more strongly implies a graphical stacking order than the imperative order they get when added in C++. This change adds QGraphicsItem::stackBefore(const QGraphicsItem *), which works similarily to QWidget::stackUnder(). It moves the item in front of the sibling item passed as an argument. While implementing this function, and writing tests for how this function behaves in combination with Z values, I found that the code we had for updating siblingIndex was broken in the case where you remove an item from the middle of the children list. In this case newly added items would be assigned the same sibling index order as one that's already in the list. So in order to get the tests to pass I had to fix this bug as well.. The approach is to sort the children list by insertion order, so that we can fix up the sibling indexes. Performancewise this has little implications. If there are gaps in the sibling index list, which only occurs if you remove an item from the middle of the children list, will the sibling index list be adjusted / corrected before used (for example, by stackBehind()). Multiple calls to stackBehind will be fast, and the list is flagged for resorting (including Z order). Reviewed-by: jasplin
* | Small API addition: Make addChildLayoutItem available for subclasses.Jan-Arve Sæther2009-09-232-0/+19
| | | | | | | | | | | | | | | | Many people have requested this. And since its protected it does not really pollute the API a lot. Task: QTBUG-3524 Reviewed-by: mbm
* | Inverts the SortOrder in graphics scene to reflect the stacking orderLeonardo Sobral Cunha2009-09-228-37/+37
| | | | | | | | | | | | | | | | Inverted all references of Qt::AscendingiOrder <-> Qt::DescendingOrder to make the order parameter consistent with the stacking order, as stated in the docs. The graphics scene index was using the wrong ordering convention. Reviewed-by: andreas
* | Fix focus scope bugs, verified against examples in kinetic-declarativeui.Andreas Aardal Hanssen2009-09-222-29/+18
| | | | | | | | | | | | | | The C++ autotests have been updated to match the expected behavior of the examples that broke (e.g., listview.qml) in kinetic-declarativeui. Reviewed-by: Alexis
* | Fixes some warning in headersOlivier Goffart2009-09-221-2/+2
| | | | | | | | | | | | | | | | | | such as margins.h:90: warning: declaration of ???bottom??? shadows a member of _this_" 'a' stands for argument Reviewed-by: jbache
* | Merge commit 'origin/4.5' into 4.6Andreas Aardal Hanssen2009-09-221-2/+4
|\ \ | |/ | | | | | | | | Conflicts: src/corelib/kernel/qcoreapplication.cpp tests/auto/windowsmobile/test/tst_windowsmobile.cpp
generated by cgit v0.12 at 2024-10-25 23:42:06 (GMT)