Qt Forum

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

    Unsolved Can a class derived from QGraphicsWidget override boundingRect()?

    General and Desktop
    2
    4
    748
    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.
    • P
      patrcki last edited by patrcki

      We have a class that is derived from QGraphicsWidget that overrides boundingRect(). This seems a little counter-intuitive to me given that boundingRect() (which is a pure virtual function of QGraphicsItem) is already implemented by QGraphicsWidget. I'm keen to know if this aligns to best practices as the QGraphicsWidget docs aren't very clear on this.

      A few more details about our class implementation:

      • boundingRect() has been overridden to return the collision geometry.
      • resize() is being called such that rect() returns a RectF that represents the actual model data (the are we paint). This can be smaller than the collision geometry -- we force the object to have a minimum collision size in the boundingRect() function.

      Is this an ill-advised setup? Are there any repercussions for doing this?

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

        Question is why you use QGraphicsWidget at all, instead of QGraphicsItem or QGraphicsObject?

        In my book, there are three main reasons to use QGraphicsWidget:

        • I want to use QGraphicsLayouts
        • I want something with a geometry I can explicitly set, instead of having to write my own logic for that.
        • I am lazy and don't want to reimplement boundingRect and paint
        P 1 Reply Last reply Reply Quote 1
        • P
          patrcki last edited by

          This post is deleted!
          1 Reply Last reply Reply Quote 0
          • P
            patrcki @Asperamanca last edited by

            @Asperamanca Thanks for the reply, that makes total sense! We'll look to rectify this bit of code -- it's functional as is but doesn't seem like good practice.

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