Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Question on model/view design: ListView with model that does not own the data
Qt 6.11 is out! See what's new in the release blog

Question on model/view design: ListView with model that does not own the data

Scheduled Pinned Locked Moved Solved General and Desktop
3 Posts 3 Posters 315 Views 1 Watching
  • 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.
  • J Offline
    J Offline
    Joachim W
    wrote on last edited by
    #1

    A QListView has a model M that inherits from QAbstractListModel. Model M represents some data D.

    Standard design seems to be that M owns D. To remove an item from D, we would first call QAbstractListModel::beginRemoveRows before actually removing the item, and similarly for other operations. Therefore, all data manipulations should take place in member functions of M.

    However, in our application, data D are to be manipulated not only by QListView but also by some other mechanism. Preferably that other mechanism should only see D, not M. After changing D, we can emit a signal S.

    So our class M only implements functions rowCount and data, which have read access to D. There will be no calls to beginRemoveRows and similar functions.

    Question: How to react to signal S so that the list view is redrawn using the latest state of D? Just call repaint???

    M 1 Reply Last reply
    0
    • J Joachim W

      A QListView has a model M that inherits from QAbstractListModel. Model M represents some data D.

      Standard design seems to be that M owns D. To remove an item from D, we would first call QAbstractListModel::beginRemoveRows before actually removing the item, and similarly for other operations. Therefore, all data manipulations should take place in member functions of M.

      However, in our application, data D are to be manipulated not only by QListView but also by some other mechanism. Preferably that other mechanism should only see D, not M. After changing D, we can emit a signal S.

      So our class M only implements functions rowCount and data, which have read access to D. There will be no calls to beginRemoveRows and similar functions.

      Question: How to react to signal S so that the list view is redrawn using the latest state of D? Just call repaint???

      M Offline
      M Offline
      mpergand
      wrote on last edited by mpergand
      #2

      @Joachim-W said in Question on model/view design: ListView with model that does not own the data:

      Question: How to react to signal S so that the list view is redrawn using the latest state of D? Just call repaint???

      Call listView->reset()

      void QAbstractItemView::reset()
      Reset the internal state of the view.
      Warning: This function will reset open editors, scroll bar positions, selections, etc. Existing changes will not be committed. If you would like to save your changes when resetting the view, you can reimplement this function, commit your changes, and then call the superclass' implementation.

      @Joachim-W said

      Standard design seems to be that M owns D.

      No, only a weak reference suffice. Usely it is owned by the window/widget where the list/table/tree views are ( the controller in the MVC paradigm)

      C 1 Reply Last reply
      0
      • M mpergand

        @Joachim-W said in Question on model/view design: ListView with model that does not own the data:

        Question: How to react to signal S so that the list view is redrawn using the latest state of D? Just call repaint???

        Call listView->reset()

        void QAbstractItemView::reset()
        Reset the internal state of the view.
        Warning: This function will reset open editors, scroll bar positions, selections, etc. Existing changes will not be committed. If you would like to save your changes when resetting the view, you can reimplement this function, commit your changes, and then call the superclass' implementation.

        @Joachim-W said

        Standard design seems to be that M owns D.

        No, only a weak reference suffice. Usely it is owned by the window/widget where the list/table/tree views are ( the controller in the MVC paradigm)

        C Offline
        C Offline
        ChrisW67
        wrote on last edited by
        #3

        If D can issue signals then those signals can trigger necessary actions in M that will, in turn, updates in all attached views (can be more than one).
        At the coarse level trigger something like:

        void M::dChanged() {
          beginResetModel();
          // refresh/discard any cached internal state M has about D
          endResetModel()
        }
        

        If you get D to issue finer grained signals e.g., rowDeleted(uuid) , then you may be able to do finer things within M in response. This is desirable from a user view perspective.

        1 Reply Last reply
        0
        • J Joachim W has marked this topic as solved on

        • Login

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Users
        • Groups
        • Search
        • Get Qt Extensions
        • Unsolved