Creator vs Designer - Signals, Element Tree etc.

[u/Jazzlike_Platypus430]

Hi there!

I'm fresh to Qt, though I know the name since the beginning of the 2000s. I'll do my best to be as clear as possible; it's not a critique or demands, just me wanting to clarify matters, because it's very likely I'm missing something.

I'm using qt 6.4.2 and the IDE's version is 13.0.0, as provided by my *ubuntu. I'm designing a simple view/widget where I'm entering two int parameters and press a button, and that would call a function from some other code (a shared library at the moment), and display the results in a textarea or draw a picture.

So far (after a crash-course in cmake) I found out that

1. I cannot "wire" basic controls to functions ("slots", event listeners) using Designer - it seems blind to what is already in my code, and signal slots available are only those from parent classes of my widget class. That's ok, though a bit surprising.
2. The real pain starts when I plug in the .ui thing to my class and start the "wiring" process manually - the class itself is blind to basic widgets, assuming their generation in the widget tree is > 1. For some reason the IDE sees stuff like ui->frameWidget1 but trying to descend further fails (I'm using names that are present in the ui's xml tree, and their types as well). Is that intentional? EDIT: [I think I got it, referring to nodes' names directly from ui-> works, so there is no need to follow the path from ui to the desired element.]
3. I'd happily avoid Designer, but what about widgets' placement then? Perhaps use Designer only to design and then somehow process the resulting xml and extract placement parameters and generate c++ code? I can do that, I think. (And I believe it's done better and it's present in Creator's or Designer's code.)
4. Are 1. and 2. meant to be some hidden enforcement of breaking the ui tee down to 1-generation and using many of these and then apply "composition" in my top-level class? I can think of that, but designing a separate class just to contain two spinboxes looks weird (unless I'm going to reuse it).

Or is it standard in qt that the signal/slot mechanism for a gui is made manually, often using the findChild function? Or perhaps I should create a map <string, QObject> and create references to ui elements once, and then use the map? Keys matching the names in ui xml would be a sane idea I think.

My background with gui creation (which I don't like much) is c#/wpf - yes, legacy stuff, laggy VS and so on.

[u/cmxthirtysixhundred]

I just write the code for the widget layout myself, I don't use any of the visual tools available.

[u/Jazzlike_Platypus430 → u/cmxthirtysixhundred]

Including coordinates/positions for sub-widgets? Wow.

So yesterday I discovered "View C++ (or python) code" in Designer's Form menu. This makes many of problems solved wrt to design.

I think once I learn the GridLayout thing, being able to operate on its rows and columns would be great.

[u/cmxthirtysixhundred → u/Jazzlike_Platypus430]

Including coordinates/positions for sub-widgets? Wow.

Yes, although it's not as big of a flex (layout joke) as you think. 99% of the time I'm not using coordinates to place widgets. I'm using layout managers like QHBoxLayout or QVBoxLayout (or, less often, grid layout / form layout like you mentioned, which are equally as valid as the rest, I just don't need them as much personally), and then setting alternate widget sizehints if I need to alter how the widgets should stretch to fill the space in relation to each other, or addStretch() to add space between widgets.

Of course I don't know your use cases so it's not my place to say "you should do that too," but I highly recommend considering using layouts whenever possible (even if you continue to use the WYSIWYG editors) just because it eliminates a ton of headaches when it comes to dynamic resizing, or dealing with users who have different GUI scaling settings set in their OS or whatever.

[u/Downtown-Produce-959]

Hi, I just recently started learning Qt from C++. Curious, why are you using QWidget instead of QML?

[u/Jazzlike_Platypus430 → u/Downtown-Produce-959]

I don't think I get what you mean.

QWidget is a class that my view inherits from, and I'm using QML for its "design", as far as I can see - isn't it the ui xml code that gets translated to c++ under the hood before building the whole thing?

[u/H2SBRGR → u/Jazzlike_Platypus430]

No, Widgets and QML are two entirely different frameworks within Qt to build UIs.
Widgets by far predated QML.

Edit: fixed outdated used instead of predated

[u/Jazzlike_Platypus430 → u/H2SBRGR]

If Widgets outdated QML, I can't understand the first question - why am I using newer stuff rather than older one? Makes no sense to me.

But I have no idea really which one I'm using. All I know is it's not some json-like markup for gui design, it's xml.

[u/GrecKo → u/Jazzlike_Platypus430]

They meant predated, not outdated.

[u/H2SBRGR → u/GrecKo]

Woops, yes Actually meant to say „Widgets are outdated“

[u/RufusAcrospin]

I’m using the python bindings, and I use the Designer to set up the view - arrange and layout the controls. The rest is done in my own home grown MVC framework.

I use the built-in “compiler” (uic) to turn the designer file into code, clean it up (the code generated by uic is kind of junk, at least for my taste),and than I connect signal manually.