Qt Forum

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

    Update: Forum Guidelines & Code of Conduct

    Unsolved Requesting help with class structures

    General and Desktop
    2
    6
    863
    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
      glennib last edited by

      Hi,

      I'm trying to design a GUI which is supposed to communicate with some hardware that I'm making. The hardware is logging some data, can be controlled and read via Mavlink-messages. The structure is something like this: http://i.imgur.com/OXHBhWh.png.

      What I'm having trouble with is how to divide the GUI into classes. I don't know how to do it "cleanly". I've designed a couple of GUIs before, and it ended up being messy, sort of like a card-house. Lots of dependencies up and down in the stack, which didn't scale well.

      What I want the GUI to be able to do is:

      1. read and control the hardware, via serial communication
      2. log whatever's being read into a database
      3. be easily expanded with additional data being sent/received to/from the hardware

      What I need help with is this:

      How do I most efficiently structure the classes so that point 3 is maintained? My initial thought is this: http://i.imgur.com/SbECvZ2.png, but it really doesn't look scalable. Is there any specific patterns I should use for this type of design?

      Any help is appreciated. Thanks.

      1 Reply Last reply Reply Quote 0
      • SGaist
        SGaist Lifetime Qt Champion last edited by

        Hi and welcome to devnet,

        Does your GUI have anything to do with that database ?

        As for the dependency problem, do you mean you have tight coupling issues with your software ?

        Interested in AI ? www.idiap.ch
        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

        G 1 Reply Last reply Reply Quote 0
        • G
          glennib @SGaist last edited by

          @SGaist Thanks for your answer.

          The database connected to the GUI should store the logged information.

          The previous GUIs I have designed have what you're calling tight coupling issues yes. Essentially what I'm asking is how to think to avoid such issues with the GUI I'm making now.

          Do you have any suggestions?

          1 Reply Last reply Reply Quote 0
          • SGaist
            SGaist Lifetime Qt Champion last edited by

            The the first question, is it really the role of the GUI to store these information ?

            One way to avoid thigh coupling is to write your classes so that they follow the Single Responsibility principle. e.g. your controller class should only provide the information that your GUI will use. It's not it's role to write a status information in your main window. It can make it available through a property but who makes use of this property is not of his concern.

            Interested in AI ? www.idiap.ch
            Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

            1 Reply Last reply Reply Quote 0
            • G
              glennib last edited by

              So your suggestion is to make a controller which is a layer between the visual elements and the data and communication?

              Thanks for your advice.

              1 Reply Last reply Reply Quote 0
              • SGaist
                SGaist Lifetime Qt Champion last edited by

                That's one way yes. Having a clean separation between both will allow you to easily change your GUI. For example change from widgets to QML.

                Interested in AI ? www.idiap.ch
                Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

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