Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Correct usage of QAbstractItemModel with a recursive data structure

    General and Desktop
    2
    2
    546
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      GlynAdgie last edited by

      I have an recursive data structure, to hold configuration data for a sound synthesiser. I already have a means to serialise this. Now I wish to provide a viewing/editing interface using the Qt model/view framework. The data structure may be thought of as an archive, i.e. it is structured rather like a filesystem. There are data items held in sections, and sections may contain subsections, like this:

      @
      instruments/
      Violin/
      config
      builder
      Viola/
      config
      builder
      Cello/
      config
      builder
      @

      The data structure is currently implemented using std::map, but I could use QMap. Items are looked up by name. Data items are Lua code stored in std::strings, but I think QByteArray would be better, as it can do compression and more.

      An obvious way to present this data is with a QTreeView, and a subclass of QStandardItemModel could be used as the interface between the view and the data. But how do I access my data items via the model? Should each QStandardItem hold a pointer to a data or section item? Or should I keep a copy of an item's name in its corresponding QStandardItem, so I can look up items in maps on demand?

      1 Reply Last reply Reply Quote 0
      • A
        andre last edited by

        I'd advise againt using QStandardItemModel for this. You'll end up duplicating your data structure.

        Instead, think of your model as an adaptor between your existing data store, and the Qt model/view API. So, have your model use your existing, underlying data model instead of re-doing the work. That directly answers your question: there is no data in your model, so also no need to keep copies.

        1 Reply Last reply Reply Quote 0
        • First post
          Last post