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. Best way to separate a humongous QTabWidget's functionality into separate classes?
Forum Updated to NodeBB v4.3 + New Features

Best way to separate a humongous QTabWidget's functionality into separate classes?

Scheduled Pinned Locked Moved Unsolved General and Desktop
3 Posts 3 Posters 1.3k 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.
  • tmladekT Offline
    tmladekT Offline
    tmladek
    wrote on last edited by
    #1

    Hello!
    I have a widget that started out as a QTabWidget with little functionality, so it didn't matter that the class managed it all - now it's responsibilities and capabilities have grown, and I've separated the code into different files which I #included into the main file - but that isn't a very good solution, as the IDEs (neither Qt Creator nor VS) aren't suited to deal with code split like that, and logically, it didn't simplify anything.

    So, I'd like to split the functionality of each tab into its own class. My approach would be to first create .ui files and transfer all the appropriate widgets, then create a class subclassing QWidget and transfer all the code. Second, to include these new widgets into my former "main" QTabWidget, but I don't know how to do that in Qt Designer (going through the dance to make the widget a truly integrated and reusable one seems like a needlessly involved approach, as the widget is going to be included exactly once).

    I'm open to any and all suggestions, what were your ways to solve this? Thanks!

    kshegunovK 1 Reply Last reply
    0
    • m.sueM Offline
      m.sueM Offline
      m.sue
      wrote on last edited by
      #2

      You do not need to make your custom widget "fully integrated" just to use it once or more often.

      You can use your custom widget's base class, which may e.g. be just "QWidget", and then declare that it represents your custom widget. This you do by right-click on it and call the context-menu entry "Promoting widget..." like explained here (for Qt 4.8). Should work as before, though: http://doc.qt.io/qt-4.8/designer-using-custom-widgets.html

      1 Reply Last reply
      1
      • tmladekT tmladek

        Hello!
        I have a widget that started out as a QTabWidget with little functionality, so it didn't matter that the class managed it all - now it's responsibilities and capabilities have grown, and I've separated the code into different files which I #included into the main file - but that isn't a very good solution, as the IDEs (neither Qt Creator nor VS) aren't suited to deal with code split like that, and logically, it didn't simplify anything.

        So, I'd like to split the functionality of each tab into its own class. My approach would be to first create .ui files and transfer all the appropriate widgets, then create a class subclassing QWidget and transfer all the code. Second, to include these new widgets into my former "main" QTabWidget, but I don't know how to do that in Qt Designer (going through the dance to make the widget a truly integrated and reusable one seems like a needlessly involved approach, as the widget is going to be included exactly once).

        I'm open to any and all suggestions, what were your ways to solve this? Thanks!

        kshegunovK Offline
        kshegunovK Offline
        kshegunov
        Moderators
        wrote on last edited by
        #3

        @tmladek
        Do you really need to derive from QTabWidget or from QWidget for that matter? What I usually do is to initialize the generic classes "from outside", that is from a controller. Said controller I derive from QObject to be able to handle signals in it (which with c++11's lambdas isn't even needed) . Basically I do this:

        #include ui_MyForm1.h"
        #include ui_MyForm2.h"
        #include ui_MyContainerForm.h"
        
        class MyController : public QObject
        {
            Q_OBJECT
        
        public:
            MyController()
                : containerWidget(Q_NULLPTR) //< You should give a parent to the widget, this is a simplified example
            {
                 MyContainerForm containerForm;
                 containerForm.setupUi(&containerWidget); //< Initialize the widget with the container form
        
                 MyForm1 form1;
                 form1.setupUi(containerForm.form1Placeholder); //< form1Placeholder is a regular QWidget that comes from the designer
        
                 MyForm2 form2;
                 form2.setupUi(containerForm.form2Placeholder); //< form1Placeholder is a regular QWidget that comes from the designer
        
                 // Do connects for whatever I need for form1, form2, containerForm
            }
        
            QWidget containerWidget;
        }
        

        No subclassing involved, except for the one from QObject. Just my 2 cents, I don't know if that really helps you.

        Read and abide by the Qt Code of Conduct

        1 Reply Last reply
        1

        • Login

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