c99816b033
QAbstractItemModel represents a table of tables where each item can have an entire table-hierarchy as children. In practice, it is enough to support a hierarchy of rows: that's what our views can display, and what users are familiar with. With this limitation, a data structure represents a tree if it's possible to traverse that hierarchy. For each row, we need to be able to navigate to the parent row (which might be nil if the row is a top-level row), and get the (optional) list of children. To enable this, we introduce a protocol type that QGIM can be instantiated with, either explicitly or implicitly. An explicit protocol provides implementations for parentRow and childRows. Const overloads are mandatory, mutable overloads are optional and allow modifying the tree structure as well. A modifyable tree might in addition need to create a row object, as new rows have to be hooked up with parent and child relationships. And a tree must be able to destroy row objects as well when rows are removed. An implicit protocol means that the row type implements this protocol through member functions. We detect this at compile time and implement tree support for ranges with an appropriate row type. This implements a first ownership model as well: if the range was moved into the model, then the owner of the model cannot/must not do anything with the container anymore, so also cannot delete the rows. We have to do so. Detect that we are operating on a moved-in container, and delete all rows if so. To make the code more readable, use explicitly named types for the implementation of the model structure, with dedicated and clearly constrained QGIM constructors. Change-Id: Iaf19c27da6ec8604923ec7c0c2523c7d62edee50 Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.
Linux X11:
* The user must be logged in to an active desktop; you can't run the
autotests without a valid DISPLAY that allows X11 connections.
* The tests are run against a KDE3 or KDE4 desktop.
* Window manager uses "click to focus", and not "focus follows mouse". Many
tests move the mouse cursor around and expect this to not affect focus
and activation.
* Disable "click to activate", i.e., when a window is opened, the window
manager should automatically activate it (give it input focus) and not
wait for the user to click the window.