Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-20105

Data model optimized for QML views

    XMLWordPrintable

    Details

    • Type: Suggestion
    • Status: Closed
    • Priority: P3: Somewhat important
    • Resolution: Out of scope
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      The data model:

      • must be aware of the data being viewed and need only monitor that data for changes.
      • must allow optimal retrieval of data from storage and optimal exposure to QML.
      • allows threaded retrieval of data
      • "rows" in the model must have an associated type. The type could be used to select a delegate when multiple alternatives are provided.
      • the view could provide hints to the model, such as the direction of movement
      • for performance reasons, only some data may be available immediately. Other data could be provided later as it becomes available.
      • the view must be able to cancel an incomplete request if the data is no longer needed. This is common in a quickly flicked list with threaded retrieval from a slow source.
      • allow typed roles. QML can optimize when the type is known.
      • consider hierarchical models
      • consider sorting models - current models have persistent indexes to help tracking items when they're sorted.

      We must also allow others to write views and use our models. This is impossible at the moment since our internal models (XmlListModel and ListModel) use an internal model interface.

      QDeclarativeVisualDataModel is also internal, so it is not possible for 3rd party views to use our data access abstraction.

      Preliminary Results

      We experimented with a model that doesn't use roles, simply provides a QObject for each row. A convenience model caches these until no longer required by the views. We reimplemented ListModel and XmlListModel using this approach, as well as SQL model classes.

      Future work/open issues:

      • The model should notify the view of changes as a "changeset" when possible rather than individual, unconnected signals (i.e. the model should say "I've added two items, and removed 3", rather than "I've added two items" and "I've removed 3 items")
      • With a simple QObject approach, it's difficult to correctly manage the lifetime of the object. For example, if listModel.get(3) is called, when can the model delete the object returned? We've discussed some sort of simple wrapper for this, and well as a QObjectRef that would take care of references both across JS and C++.
      • Caching worked well, but it can be relatively expensive to invalidate that cache when things in the model are added/removed/moved. Need to investigate alternatives to QHash for the caching.
      • For our own models, making it easier to work with dynamic objects would be nice
      • For compatibility, we need to make sure model/modelData/index and all combinations continue to work as before. An autotest was added for this (if we are returning the actual QObject as "model", then we need to annotate it with e.g. model.index)

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

              People

              Assignee:
              qt.team.quick.subscriptions Qt Quick and Widgets Team
              Reporter:
              minshin Minjung Shin (closed Nokia identity) (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Gerrit Reviews

                  There are no open Gerrit changes