Academic question - how to manage Qt "many colors"?

SGaist

Hi,

As silly as may sound: practice.

Like for any other framework/library/application.

You have to learn and practice the tools.

On a simpler level, take protobuf. You have to learn the syntax of the description file then use the provided tool to translate that description in code for the language of your choice and then you can use it.

Chris Kawa

The tools (uic, moc, rcc) in any reasonable project beyond couple of files are automated by the build system, be it qmake, CMake, or other. After a while of getting used to you don't think about them at all. They just do what they do in the background and all you care about is editing the inputs.

As with everything there are pros and cons to using the designer. I, for example, use it very sparingly and only for scaffolding for extremely large designs, as it doesn't give you the full control over everything you can do from code. In my particular case I use a lot of custom widgets and making them work with the designer is kinda annoying.

But others have expressed different sentiments and use it extensively. It's often faster to click away a small dialog than to write it by hand from code. To each their own I guess.
My advice would be try to use it for a while and if helps you use it. If, after giving it some time, you still don't see the benefits then no harm done. It's an extra tool but it's not mandatory in any way.

Anonymous_Banned275

@ofmrew Yes and that prompted my inquiry. I guess I'll have to bite the bullet and learn XML. Hope there is no assembly code hidden somewhere else in Qt.

Anonymous_Banned275

@Chris-Kawa
I got no problem with "automation" , perhaps it is my "start with sample code" sort of top down approach to learning new stuff.
Qt is well documented , but very few official "examples" tells what is happening with the code. Or maybe they do but one has little guidance where to look.
For example QApplication a(argc, argv); should be commented in ALL examples what it does.
Is building x-ui.h from x.h documented anywhere ?
Yes, it is build automatically with new class.

YES, practice is the key , but the beginning was pretty frustrating....

PS. I can actually find and tell about my bluetooth device with MY code !
Little crude , but works.

Many thank for all help from forum.

mranger90

@AnneRanch
No, there is no reason to learn XML.
It is just the means the Qt Creator/Designer uses to store its database of what it s being presented in the editor. Don't waste your time because it should be a black box. For all we know it could change at some point in the future. If you want to design your UI strictly by using designer forms, then you just have to trust that what is presented in the designer will be on the screen.
Of course, you could also generate your UI elements on the fly, without using the designer, but that is another lesson.
There are several fundamental steps that you have to understand. QMake is a "Make Make", i.e. it generates a makefile. If you examine the generated Makefile (in the build_xxxxxx folder) you will see several steps are taken to generate the application. One of these steps is the "uic", which is the ui compiler. This turns the xml as generated in designer into c++ code which you can inspect (again in the build folder) as ui_<component>.h.

Another step is the meta-object-compiler also known as "moc", which is necessary to, historically, to generate the signals, slots and other metatype information.

Finally, all of this is fed to you C++ compiler to be built into an application.

This is why it is critical that if you make any changes to your *.pro file, that you must run qmake again to generate the make file. For reasons beyond me, a "rebuild all" operation does not do this.

Again, I would recommend viewing one of the many good step-by-step tutorials that are out there before jumping into an application. I also came from a long history with MFC. Once you understand how all of these parts fit together you wont even think about it again.

mrjj

Hi
When you use a UI files with the corresponding .h and .cpp files.
The code is generated from the XML file and you can inspect it as its normal
c++ code to realize your UI design.

MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this); <<< place cursor on setupUI and press F2

In here is all the widgets you put on the Designer form.

Anonymous_Banned275

@mranger90

Sorry, just found ONE reason to learn XML!

When I added file from examples I somehow used "#include ui_device.h"
But my form file is just "device.h" and I cannot find it to edit it.
And when I open "ui_device.h" I get warning that the file is outside project.
I got things mixed up pretty badly.
I need to find the actual XML code which "links" the "ui_x.h "file to the class.
And taat is the one I want to edit and use.

That should not be that hard.

jsulm

@AnneRanch said in Academic question - how to manage Qt "many colors"?:

And taat is the one I want to edit and use.

You should never edit generated code! Reason: next time you build your project the files will be regenerated and all your changes will be lost! If you use designer, then you have to accept that some code will be generated. If you do not want this then do not use desugner and write everything by yourself.

"Is building x-ui.h from x.h documented anywhere ?" - for example here: https://doc.qt.io/qt-5/qtdesigner-calculatorform-example.html

Pl45m4

@AnneRanch said in Academic question - how to manage Qt "many colors"?:

OK, after assigning tool tip in code I found no corresponding text in QDesigner. ( yes it compiles / runs and shows the tool tip !)

If you access and change UI-elements by using your code, these changes will not appear in your QtDesigner file afterwards.
It happens on runtime / while compilation and will not change your (QtDesigner-) GUI-definition file.

@AnneRanch said in Academic question - how to manage Qt "many colors"?:

When I added file from examples I somehow used "#include ui_device.h"
But my form file is just "device.h" and I cannot find it to edit it.

The yourGUI.ui file (XML style, QtDesigner output, device.ui in your case, if you have one) contains your GUI definitions from QtDesigner and is translated into ui_device.h (C++ GUI Header) automatically.
Your "normal" (c++) header (device.h) includes this UI-header-file to provide you access to your GUI by code (from device.cpp)

In fact this process is repeated every time you compile your program, there is no need to edit files like ui_someClassName.h or even someClassName.ui. The second one actually is editable with any text editor (XML code), if you know what you are doing, but I think nobody would recommend that. (stick with QtDesigner in terms of editing these *.ui-files)

It's nice to know how these moc, uic, qmake processes work and what they do in general, but you dont have to understand every single detail :)

@AnneRanch said in Academic question - how to manage Qt "many colors"?:

I got things mixed up pretty badly.
I need to find the actual XML code which "links" the "ui_x.h "file to the class.

If you messed up your project, do a "cleanup" / "rebuild" or delete your build-folder from OS. Then run qmake / build again.
This will force new, clean UI-headers and build directories.

Anonymous_Banned275

@mrjj

@Pl45m4 said in Academic question - how to manage Qt "many colors"?:

@AnneRanch said in Academic question - how to manage Qt "many colors"?:

OK, after assigning tool tip in code I found no corresponding text in QDesigner. ( yes it compiles / runs and shows the tool tip !)

If you access and change UI-elements by using your code, these changes will not appear in your QtDesigner file afterwards.
It happens on runtime / while compilation and will not change your (QtDesigner-) GUI-definition file.

@AnneRanch said in Academic question - how to manage Qt "many colors"?:

When I added file from examples I somehow used "#include ui_device.h"
But my form file is just "device.h" and I cannot find it to edit it.

The yourGUI.ui file (XML style, QtDesigner output, device.ui in your case, if you have one) contains your GUI definitions from QtDesigner and is translated into ui_device.h (C++ GUI Header) automatically.
Your "normal" (c++) header (device.h) includes this UI-header-file to provide you access to your GUI by code (from device.cpp)

In fact this process is repeated every time you compile your program, there is no need to edit files like ui_someClassName.h or even someClassName.ui. The second one actually is editable with any text editor (XML code), if you know what you are doing, but I think nobody would recommend that. (stick with QtDesigner in terms of editing these *.ui-files)

It's nice to know how these moc, uic, qmake processes work and what they do in general, but you dont have to understand every single detail :)

OK, it is beginning to gel.
Using the following example , basically Qt generated "mainwindow" I like to get somebody to help me annotate the source code or just very if I am doing it right. It may be redundant or silly basic C++ stuff but with all these "automated " things going in Qt "background" I find it necessary to really understand the processes.

Allow me to restate my goal - to have a simple GUI to run my data processing application. I am not after fancy graphics, just an interface ( for now ).

Here is my view at things as they are build .

Qt make runs GCC complier and builds plain C / C++ "main" .

Same process , with addition of XML and qmake (?) , builds source file for "main window"

The attached sample code contains
mainwindow header - standard C/C++ header file
ui_mainwindow "header" - a file created by QDesigner
the graphic is visible, editable using QDesigner
the "code " is build using XML during "compile" and
NOT transferred to any C source
AFTER compile there is an XML file somewhere (?) and since it is generated it should not be edited BUT is useful to find out what it is doing

Then there is a standard C++ constructor , fine.
BUT how do I make sure the "ui_main window.h" IS the form this (?) constructor is using?
(Do I need refresher course on "this" command / syntax?)

In my convoluted case I have been editing wrong form.

All this may be basic , child’s play for some, but it is driving me nuts.
I do not readily see C code changes I make in QDesigner form, should not edit invisible XML file during edit mode , but can add data processing code to constructor ( in this example) and execute it - sort-of "on top of XML" file.
My C++ code does not show in "form" and I am not sure if it is in XML either - it should not be there

Anonymous_Banned275

@Pl45m4

Your "normal" (c++) header (device.h) includes this UI-header-file to provide you access to your GUI by code (from device.cpp)
I have
#include C header
#include "ui_same name as C header "

in cpp file
It was build that way by Qt new class process.
Is that OK?

Chris Kawa

@AnneRanch You got some of it wrong, some of it right.

Here's how it goes:

You've got a mainwindow.h file with a MainWindow class declaration that you edit in a text editor as normal c++.
You've got a mainwindow.cpp file with MainWindow class definition that you edit in a text editor as normal c++.
You've got a mainwindow.ui file in xml format that you edit with the designer. You don't need to touch xml directly in text editor.

You press build.

qmake generates make rules that run moc on the mainwindow.h file and generate moc_mainwindow.cpp file
qmake generates make rules that run uic on the mainwindow.ui file and generate ui_mainwindow.h file
Files mainwindow.h, mainwindow.cpp, moc_mainwindow.cpp and ui_mainwindow.h, all standard c++, are sent to compiler.
mainwindow.ui (the xml) is not compiled or used at runtime. Its only purpose is generating ui_mainwindow.h and it's a one-way thing.

Now as to actual contents of the files:

ui_mainwindow.h has a c++ class Ui_MainWindow with a single method setupUi(QMainWindow*) and an empty class Ui::MainWindow (notice the namespace) that inherits from Ui_MainWindow.

mainwindow.h has a forward declaration of that Ui::MainWindow class and a declaration of your class MainWindow which has a pointer member called ui of type Ui::Mainwindow* (the class generated in ui_mainwindow.h).

mainwindow.cpp includes your own mainwindow.h and the generated ui_mainwindow.h. It also has the definition of your class MainWindow. In its constructor it creates an instance of the class Ui::MainWindow and assigns it to the ui variable. Then it calls ui->setupUi(this) and this is the c++ code that was generated from .ui file via uic, that adds all the widgets to this and sets up all their properties. The ui member is also how you interact with the generated content from your own code. It has members for all the widgets you set up in the designer.

To reiterate - You edit mainwindow.h and mainwindow.cpp as normal c++. You edit the .ui file through the designer. You don't touch the generated files ui_xxx and moc_xxx.

EDIT: Updated to reflect SGaist's comment.

Pl45m4

@Chris-Kawa

This.

Best summary of the Qt build / moc / compilation process I've seen (and probably the best you can find on the Internet)

SGaist

One small correction: qmake doesn't run anything.

It will generate "build" rules corresponding to .ui files so that uic is run as @Chris-Kawa described and the same goes for QObject based class.

When build is pressed, make (or its equivalent) follows these rules and calls the corresponding tools.

Chris Kawa

@SGaist Thanks, I guess I simplified it one bit too much :)

Anonymous_Banned275

@Pl45m4 Interesting observation we could discuss / analyse, but later. I am scheduled for surgery so I'll be absent here for a spell.

JonB

@AnneRanch
As we have said we are a (hopefully) a friendly forum, so all the best for your surgery.

Anonymous_Banned275

@Chris-Kawa
Chris, you are "THE MAN".
I do not have much time to reply.
At this point I see Qt Creator as these "puzzle parts"
and estimated percentage of my understanding how the parts fits into the whole
C++ 99%
project 80%
main 90%
mainwindow need to really read and digest your post
application class 50%

My next concern is
I can instantiate the app class in "main"
I can execute "button press" on mainwindow

the missing piece is how to execute app class function .

As stupid as it sounds , my guess is the app class instance is in wrong place thus still showing I do not fully get the relations between the GUI class "mainwindow" and "main". and the app class of course.

jsulm

@AnneRanch I guess you mean this:

#include <QApplication>
#include "mainwindow.h"

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    MainWindow mainWin; // Your main window instance
    mainWin.show(); // This shows your main window on the screen, this call does not block
    return app.exec(); // This starts the Qt event loop (https://doc.qt.io/qt-5/qapplication.html#exec). exec() call does not return until your application is closed.
}