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. Support for constructing QStandardItem objects from QVariant references?
Forum Updated to NodeBB v4.3 + New Features

Support for constructing QStandardItem objects from QVariant references?

Scheduled Pinned Locked Moved Unsolved General and Desktop
qstandarditemqvariantdata modelscustom dataconstruction
27 Posts 5 Posters 8.8k Views 2 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.
  • E elfring

    … that takes the custom type directly, without having to do QVariant conversion:

    I imagine that this another software development challenge if you need to work with the provided generic (or standard) programming interfaces.

    class MyItem : public QStandardItem {
    …
    MyData *m_data;
    };

    I find the specification of this member variable questionable for such a software design approach because the base class should take care of the desired data storage.
    You might add attributes there for other design reasons.

    JKSHJ Offline
    JKSHJ Offline
    JKSH
    Moderators
    wrote on last edited by JKSH
    #18

    @elfring said in Support for constructing QStandardItem objects from QVariant references?:

    … that takes the custom type directly, without having to do QVariant conversion:

    I imagine that this another software development challenge if you need to work with the provided generic (or standard) programming interfaces.

    Sorry, I didn't understand this. Could you rephrase it?

    I find the specification of this member variable questionable for such a software design approach because the base class should take care of the desired data storage.

    That's true, but you also didn't like converting/copying data in/out of QVariant. That's why I suggested this design, as a compromise to meet your different goals.

    Like I mentioned before, QStandardItemModel is not well-suited for handling custom data structures. If you want a clean software design AND avoid converting/copying data, then avoid QStandardItemModel. Subclass QAbstractItemModel instead.

    Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

    E VRoninV 2 Replies Last reply
    1
    • JKSHJ JKSH

      @elfring said in Support for constructing QStandardItem objects from QVariant references?:

      … that takes the custom type directly, without having to do QVariant conversion:

      I imagine that this another software development challenge if you need to work with the provided generic (or standard) programming interfaces.

      Sorry, I didn't understand this. Could you rephrase it?

      I find the specification of this member variable questionable for such a software design approach because the base class should take care of the desired data storage.

      That's true, but you also didn't like converting/copying data in/out of QVariant. That's why I suggested this design, as a compromise to meet your different goals.

      Like I mentioned before, QStandardItemModel is not well-suited for handling custom data structures. If you want a clean software design AND avoid converting/copying data, then avoid QStandardItemModel. Subclass QAbstractItemModel instead.

      E Offline
      E Offline
      elfring
      wrote on last edited by
      #19

      Could you rephrase it?

      The class “QVariant” is a generic programming interface for the handling of known data structures.

      That's true,

      Thanks for your acknowledgement.

      but you also didn't like converting/copying data in/out of QVariant.

      Yes. - Thus I am looking again for useful software adjustments there.

      Subclass QAbstractItemModel instead.

      I would appreciate if I can reuse existing functionality from a higher level base class.

      JKSHJ 1 Reply Last reply
      0
      • JKSHJ JKSH

        @elfring said in Support for constructing QStandardItem objects from QVariant references?:

        … that takes the custom type directly, without having to do QVariant conversion:

        I imagine that this another software development challenge if you need to work with the provided generic (or standard) programming interfaces.

        Sorry, I didn't understand this. Could you rephrase it?

        I find the specification of this member variable questionable for such a software design approach because the base class should take care of the desired data storage.

        That's true, but you also didn't like converting/copying data in/out of QVariant. That's why I suggested this design, as a compromise to meet your different goals.

        Like I mentioned before, QStandardItemModel is not well-suited for handling custom data structures. If you want a clean software design AND avoid converting/copying data, then avoid QStandardItemModel. Subclass QAbstractItemModel instead.

        VRoninV Offline
        VRoninV Offline
        VRonin
        wrote on last edited by
        #20

        @JKSH said in Support for constructing QStandardItem objects from QVariant references?:

        QStandardItemModel is not well-suited for handling custom data structures.

        I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes

        @elfring said in Support for constructing QStandardItem objects from QVariant references?:

        I would appreciate if I can reuse existing functionality from a higher level base class.

        Since we are moving one step higher, why not be even more generic:
        QAbstractItemModel* model = new QStandardItemModel(parent);

        This allows you to:

        1. use QStandardItemModel instead of subclassing your own
        2. use your custom data types seamlessly as QAbstractItemModel always uses QVariant
        3. Lets you abstract the implementation of the model by using the API that is guaranteed to be available in every model

        "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
        ~Napoleon Bonaparte

        On a crusade to banish setIndexWidget() from the holy land of Qt

        E JKSHJ 2 Replies Last reply
        0
        • VRoninV VRonin

          @JKSH said in Support for constructing QStandardItem objects from QVariant references?:

          QStandardItemModel is not well-suited for handling custom data structures.

          I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes

          @elfring said in Support for constructing QStandardItem objects from QVariant references?:

          I would appreciate if I can reuse existing functionality from a higher level base class.

          Since we are moving one step higher, why not be even more generic:
          QAbstractItemModel* model = new QStandardItemModel(parent);

          This allows you to:

          1. use QStandardItemModel instead of subclassing your own
          2. use your custom data types seamlessly as QAbstractItemModel always uses QVariant
          3. Lets you abstract the implementation of the model by using the API that is guaranteed to be available in every model
          E Offline
          E Offline
          elfring
          wrote on last edited by
          #21

          It is not performance-efficient

          Will this information trigger any further software evolution?

          but it is generic enough to handle all kinds of custom metatypes

          This design aspect is reasonably documented.

          Since we are moving one step higher, why not be even more generic:
          QAbstractItemModel* model = new QStandardItemModel(parent);

          This data structure combines standard (or also custom) items.

          use QStandardItemModel instead of subclassing your own

          A derivation from an item class is needed if you would like to add member functions there.
          It is a matter how the desired software behaviour is assigned to specific items or corresponding models overall.

          JKSHJ 1 Reply Last reply
          0
          • E elfring

            It is not performance-efficient

            Will this information trigger any further software evolution?

            but it is generic enough to handle all kinds of custom metatypes

            This design aspect is reasonably documented.

            Since we are moving one step higher, why not be even more generic:
            QAbstractItemModel* model = new QStandardItemModel(parent);

            This data structure combines standard (or also custom) items.

            use QStandardItemModel instead of subclassing your own

            A derivation from an item class is needed if you would like to add member functions there.
            It is a matter how the desired software behaviour is assigned to specific items or corresponding models overall.

            JKSHJ Offline
            JKSHJ Offline
            JKSH
            Moderators
            wrote on last edited by
            #22

            @elfring said in Support for constructing QStandardItem objects from QVariant references?:

            It is not performance-efficient

            Will this information trigger any further software evolution?

            No. Because... (see below)

            I would appreciate if I can reuse existing functionality from a higher level base class.

            ...remember, engineering involves finding the right balance. In general, these are the trade-offs when you choose a high-level API:

            • Pros:
              • Simple, easy to use
              • More protections against errors
            • Cons:
              • Less performant
              • Less flexible

            When you choose the pros of the high-level QStandardItemModel, you also choose the cons.

            Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

            E 1 Reply Last reply
            1
            • VRoninV VRonin

              @JKSH said in Support for constructing QStandardItem objects from QVariant references?:

              QStandardItemModel is not well-suited for handling custom data structures.

              I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes

              @elfring said in Support for constructing QStandardItem objects from QVariant references?:

              I would appreciate if I can reuse existing functionality from a higher level base class.

              Since we are moving one step higher, why not be even more generic:
              QAbstractItemModel* model = new QStandardItemModel(parent);

              This allows you to:

              1. use QStandardItemModel instead of subclassing your own
              2. use your custom data types seamlessly as QAbstractItemModel always uses QVariant
              3. Lets you abstract the implementation of the model by using the API that is guaranteed to be available in every model
              JKSHJ Offline
              JKSHJ Offline
              JKSH
              Moderators
              wrote on last edited by
              #23

              @VRonin said in Support for constructing QStandardItem objects from QVariant references?:

              @JKSH said in Support for constructing QStandardItem objects from QVariant references?:

              QStandardItemModel is not well-suited for handling custom data structures.

              I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes

              I agree that it's generic enough to handle custom types. I just don't think it handles them nicely. (And to clarify, I was talking about custom, multi-element data structures that can't be easily represented by 1 string.)

              My main gripe is this: 1 Item represents 1 "cell" in the View, and by default each cell only shows 1 "element". Thus, if I were to squeeze a complex multi-element data structure into an Item, then I'd need to write a custom Delegate too.

              But anyway, this is a matter of personal preference. There's still a place for QStandardItemModel and I'm still happy to help someone use it if they want to.

              Since we are moving one step higher, why not be even more generic:

              I believe that's going lower-level, not higher-level... right...?

              Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

              VRoninV 1 Reply Last reply
              0
              • JKSHJ JKSH

                @elfring said in Support for constructing QStandardItem objects from QVariant references?:

                It is not performance-efficient

                Will this information trigger any further software evolution?

                No. Because... (see below)

                I would appreciate if I can reuse existing functionality from a higher level base class.

                ...remember, engineering involves finding the right balance. In general, these are the trade-offs when you choose a high-level API:

                • Pros:
                  • Simple, easy to use
                  • More protections against errors
                • Cons:
                  • Less performant
                  • Less flexible

                When you choose the pros of the high-level QStandardItemModel, you also choose the cons.

                E Offline
                E Offline
                elfring
                wrote on last edited by
                #24

                …, you also choose the cons.

                I would prefer to adjust the remaining development challenges somehow in this area.

                1 Reply Last reply
                0
                • JKSHJ JKSH

                  @VRonin said in Support for constructing QStandardItem objects from QVariant references?:

                  @JKSH said in Support for constructing QStandardItem objects from QVariant references?:

                  QStandardItemModel is not well-suited for handling custom data structures.

                  I disagree. It is not performance-efficient but it is generic enough to handle all kinds of custom metatypes

                  I agree that it's generic enough to handle custom types. I just don't think it handles them nicely. (And to clarify, I was talking about custom, multi-element data structures that can't be easily represented by 1 string.)

                  My main gripe is this: 1 Item represents 1 "cell" in the View, and by default each cell only shows 1 "element". Thus, if I were to squeeze a complex multi-element data structure into an Item, then I'd need to write a custom Delegate too.

                  But anyway, this is a matter of personal preference. There's still a place for QStandardItemModel and I'm still happy to help someone use it if they want to.

                  Since we are moving one step higher, why not be even more generic:

                  I believe that's going lower-level, not higher-level... right...?

                  VRoninV Offline
                  VRoninV Offline
                  VRonin
                  wrote on last edited by
                  #25

                  @JKSH said in Support for constructing QStandardItem objects from QVariant references?:

                  then I'd need to write a custom Delegate too.

                  100% agree on this point

                  I believe that's going lower-level, not higher-level

                  I meant higher level of abstraction (i.e. just look at the interface, not the implementation)

                  I would prefer to adjust the remaining development challenges somehow in this area.

                  Then a custom model is the way to go but it is not easy for people approaching Qt for the first time.

                  P.S.
                  It might be just a language issue but this is not StackOverflow, you won't get shouted at if you don't use exact technical terminology all the time, you can relax

                  "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                  ~Napoleon Bonaparte

                  On a crusade to banish setIndexWidget() from the holy land of Qt

                  JonBJ 1 Reply Last reply
                  1
                  • VRoninV VRonin

                    @JKSH said in Support for constructing QStandardItem objects from QVariant references?:

                    then I'd need to write a custom Delegate too.

                    100% agree on this point

                    I believe that's going lower-level, not higher-level

                    I meant higher level of abstraction (i.e. just look at the interface, not the implementation)

                    I would prefer to adjust the remaining development challenges somehow in this area.

                    Then a custom model is the way to go but it is not easy for people approaching Qt for the first time.

                    P.S.
                    It might be just a language issue but this is not StackOverflow, you won't get shouted at if you don't use exact technical terminology all the time, you can relax

                    JonBJ Offline
                    JonBJ Offline
                    JonB
                    wrote on last edited by
                    #26

                    @VRonin said in Support for constructing QStandardItem objects from QVariant references?:

                    It might be just a language issue but this is not StackOverflow, you won't get shouted at if you don't use exact technical terminology all the time, you can relax

                    +1 for pointing out that this forum is not like The Gestapo from SO!

                    1 Reply Last reply
                    0
                    • E elfring

                      Could you rephrase it?

                      The class “QVariant” is a generic programming interface for the handling of known data structures.

                      That's true,

                      Thanks for your acknowledgement.

                      but you also didn't like converting/copying data in/out of QVariant.

                      Yes. - Thus I am looking again for useful software adjustments there.

                      Subclass QAbstractItemModel instead.

                      I would appreciate if I can reuse existing functionality from a higher level base class.

                      JKSHJ Offline
                      JKSHJ Offline
                      JKSH
                      Moderators
                      wrote on last edited by
                      #27

                      @elfring said in Support for constructing QStandardItem objects from QVariant references?:

                      I would appreciate if I can reuse existing functionality from a higher level base class.

                      Sorry! I just re-read this line and realized you said "higher level base class". In this case, please ignore what I said about choosing pros and cons.

                      Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                      1 Reply Last reply
                      0

                      • Login

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