Qt, note so cute? Have I wasted enough time?

[Simon]

I done some time trying to get into Qt. At the moment my opinion is that it's a steaming pile of dog shit!
The documentation that everyone lauds is incomplete or wrong, does not matter which they both amount to the same thing.

I spent hours getting the RCC/QRC system to work, the official documentation page is just some nonspecific nonsense. Naturally when I asked on the forum all people would do is point to this documentation calling it definitive. In the end I got it to work after reading several different tutorials and watching several YouTube tutorials and piecing it all together.

So I go back to the thread and explain that I got it to work. Oh, now the guy that told me that the official documentation is kings wants to know how I did it. So I did not, yea, becoming a true programmer I am!  I explained how the documentation fails and there is of course no response.

So as I need to obviously get data from the program (C++) to the display I need to, well you know if you know Qt, C++ class that incorporates the Q_Object, this permits signals and slots that allow this communication between C++ and QML.

Naturally nothing works. I tried following a Qt academy tutorial, well that was shit. Instead of just explaining a C++ class with a Qt object using signals and slots they had to over egg it and throw a load more stuff in at which point the whole thing fails to compile and it's just too much thrown it an once.

But having tried to get something working myself and doing some more reading I see the same pattern as before when I tried to get the RCC system to work. Documentation is nonsensical and incomplete. There is conflicting information. The more I try stuff the more it falls apart.

So, is it really worth it? Surely there is a better way. All I need to do is put things on a screen representing numbers. At some point touch input would be needed. Is Qt this bad or is it something only to be used by the experienced? I've been using the Qt creator IDE, but still with that you end up in this mess.

[kripton2035]

which end processor/microcontroller/module and display are you using ?

[BBBbbb]

Qt is intended as a GUI tool for everything, thus it’s not going to be easy.
Not sure about incorrect information in the documentation, I have not run into it. Take care that you are looking at the information for the proper version. Googling can lead you to the wrong one.
About being incomplete - I do share that view to an extent, but like you I’m not really a GUI person and lack perhaps some foundation that I expect to be documented.

Regarding signals/slots. You will end up using some type of messaging to tie in the GUI. Yes QObject is a pita. Do a nice viewmodel, prefer composition, … and life will be easier.

My big issue with Qt is object lifetime which is (to my limited experience) random and thus GUI behavior doesn’t align with my expectations.
Also licensing can big a big burden depending on the product.

Just my 2 cents
There probably exists a beter option if you focus just on your use case, snoop around.

[Simon]

which end processor/microcontroller/module and display are you using ?

I'm planning to use Linux on a single board computer. My limited experience is that HDMI is the minimum standard that does not require linux voodo to get particular displays to work on certain boards/OSes. QSPI could also be an option and often is the only one for smaller screens like 7".

[Simon]

Qt is intended as a GUI tool for everything, thus it’s not going to be easy.
Not sure about incorrect information in the documentation, I have not run into it. Take care that you are looking at the information for the proper version. Googling can lead you to the wrong one.
About being incomplete - I do share that view to an extent, but like you I’m not really a GUI person and lack perhaps some foundation that I expect to be documented.

Regarding signals/slots. You will end up using some type of messaging to tie in the GUI. Yes QObject is a pita. Do a nice viewmodel, prefer composition, … and life will be easier.

My big issue with Qt is object lifetime which is (to my limited experience) random and thus GUI behavior doesn’t align with my expectations.
Also licensing can big a big burden depending on the product.

Just my 2 cents
There probably exists a better option if you focus just on your use case, snoop around.

I initially looked at FLTK. Stroustrops 2nd edition of "programming principles and practice using C++" said that FLTK was practically the de facto standard for graphics in C++. Roll on to edition 3 and now the chapter on graphics is talking about Qt, but it barely mentions that Qt is what was used for the examples. Ah but then the third edition is half the size of the second and frankly is about as useful as the Qt documentation. In fact it reads very much like the Qt documentation...... I wonder who stroustrop let edit his work?

Yea, licensing is a nightmare to understand. It looks like someone started an open source project, then changed their mind but it was too late to make the Qt core code chargeable IP so they instead concocted this monumental misunderstood mess that means that people basically pay £4k a year for.... oh, unlimited support, yes because as their website support is so lousy you need private tuition from them direct, I mean really that appears to be the only real difference between the commercial license and the community edition. And now that you have paid £4k to learn how to use it, why on earth would you help some free loader like me an a public forum where anyone can learn what you paid £4k per year for?

[Smokey]

I used Qt to make a GUI a while back.  I found it to be pretty damn good actually.  Qt creator was super helpful.  Once I got the design paradigm and the window layout system it was pretty straightforward.  Lots of information and tutorials available.  I'm sure it's only gotten better in the last 6 or so years.  Would highly recommend to a friend for a real GUI. 

Previously I tried WX Widgets, which was much harder to work with.  That was about 5 years before the Qt though so WX might have also gotten way better since then.  KiCad uses WX so it can't be that bad right

[Simon]

No, in the last 6 years they have probably not updated the documentation leaving it out of step with the software.

[ataradov]

Qt is one of the best if not the best frameworks for desktop stuff. All GUI programming sucks. Qt makes it much easier. Their preprocessor is quite annoying, but it actually enables a lot of functionality that would be hard otherwise. Their documentation is also some of the best I've seen.

No idea how it translates to embedded, especially if you don't want traditional standard-looking windows and typical desktop behavior. I get a feeling, it is not the best option for that case.

Their licensing is also pretty bad.

[nctnico]

No, in the last 6 years they have probably not updated the documentation leaving it out of step with the software.

Do yourself a favour and buy a book on how to start projects using Qt and read it. Random internet examples don't work as you still miss learning the fundamentals you need to get started. There are likely several ways on how to organise a project and choosing the right one which is most suitable is the first step.

Some people mentioned WX Widgets; for this framework goes the same: buy the book written by the creators. BTW, I have used WxWidgets for many embedded Linux projects to have standard or custom GUIs and I'm quite sure Qt can do the same. With Gnome (GTK) as the presentation layer, you can also do a lot of UI customisation by using different GTK themes and tweaking these to your liking.

[Simon]

A book you say, have you any recommendations? There seem to be precious few for Qt 6 and none of them have terrific reviews, I have bought one that was very hard to even find and it is all about QML. I need to write a C++ program, if no one wants to explain how to get C++ working with QML then I won't get anywhere. Or is it all done in QML now?

They have a PDF book on their site, I was working through that until they "just" put pictures into the QML with no further explanation. That started a 2 week crusade on getting the RCC system to work as this "book" did not mention it at all.

I suppose now is the time to be told I don't need QML although my understanding is that the widget system will be obsoleted so I have to use QT (not so) Quick instead of widgets.

[radiolistener]

In my opinion, Qt is a crazy bloatware.

The issues with documentation and similar things are all nonsense, it doesn't matters. Qt would be a decent framework due to its capabilities, but the amount of code and data that needs to be installed breaks all records - and that's terrible.

[Simon]

Well I am not so fussed about the size of the program itself although I should have bought a laptop with a bigger drive . Have you ever installed Atmel studio? I once had to write a manual for my boss on how to flash a chip and he would have to install Atmel studio to do this. I literally wrote in my instructions to go grab breakfast while it was installing as seriously, this would take 20 minutes.... And this is just for a micro controller, several GB.

The documentation is nuts though. Certainly not aimed at beginners. I have gone back to the last tutorial I did and thought I'd look through the starter code they provide. No mention of a resource file to get the images to load and yet load they do. So I am confused. I followed the online PDF book and files would not load. At first I thought they were to come from Qt creator itself but the author made no mention I tried creating my own but nothing. I know the book was originally written for Qt 5 before being updated to Qt 6 and I have noticed some Qt 5 references so at this point I really do not know if the resource files are an old or new thing or if there are just many ways of doing the same things. This makes it difficult as I never know if my setup is what the materials expect me to have.

[radiolistener]

Well I am not so fussed about the size of the program itself although I should have bought a laptop with a bigger drive

If you have plenty of disk space, you might not notice such problems. However, when a small GUI application fits into a 5-10 KB executable and works perfectly without requiring the installation of bloated libraries, and you try to rewrite it in Qt and realize it requires downloading hundreds of libraries totaling several gigabytes and unnecessarily bloats the application's code to tens of megabytes and adding dependency on gigabyte-sized libraries linked with specific version, it starts to get frustrating - even if you have plenty of disk space and your internet speed allows downloading gigabyte-sized libraries without worrying about time.

And not to mention the issues with library versions. Take, for example, the Qt samples. Some of them you simply won't be able to compile, and if you do manage to compile them, they won't work due to library version issues. The need to modify the application code to make it compile with your version of Qt is quite common issue.

For these reasons, I consider Qt to be bloatware, with the classic problem of versioning hell.

[Simon]

Yes the examples are useless, even the Qt academy tutorials seem to be out of date already.

[DiTBho]

Any container with QT dev ?
It would be the perfect case

[Nominal Animal]

Qt signal (event source) and slot (event receiver function) mechanism is funky, but not crap.  For one thing, it works across threads just fine.

The documentation issue is that there are multiple ways of referring to these, and there are differences here between major versions of Qt. There are some significant differences in the details between minor versions, so being very anal about the version being referred to is important.  Annoying, yes, but important.  Are you using Qt 6.8 or some other version?  I admit, I still prefer Qt 5 (5.12 to 5.18).

Because the slots can be overloaded –– different handler for different parameters –– you need to specify the prototype for the target slot when connecting.  If you use the string-based format (using SIGNAL() and SLOT() macros), it will be resolved at runtime; the functor (aka function pointer) based format (using &Class::signalName and &Class::slotName) is resolved at compile time.

You'll also see a lot of C++ lambda functions that capture the context variables by value, using the format [=](){ function body }.

I avoid the mess by writing the code myself, and only using Qt Creator to provide me with the user interface description file.  I do prefer the QUiLoader (XML) approach over the QML, though.  Both can be used with Qt Creator, the trick is that you don't let it generate any UI C++ code for you; the initial skeletons only, perhaps.

Automatic association of member functions to slots is based on QMetaObject::connectSlotsByName(), which looks at your main class, and connects any member functions named on_objectName_signalName to the signal signalName of UI object with name objectName.  You do not have to use it, you can also do it yourself (connect(widget,&widgetClass::signalName,receiver,&class::method), with receiver typically being the your main class instance this you do the connections in), for example when you have many objects with signals connecting to the same handler function.

When I first started using Qt, Qt Creator confused many things.  So, I did some UIs with my own code only, including creating the UI widgets at run time.  This helped me understand the widget hierarchy, and later use Qt Creator to help with my workflow, instead of forcing me to the workflow the Qt Creator developers where thinking of when creating the tool.

I can definitely relate to the frustration (even though not to the claim that this makes it utter shite), but I'd suggest doing some real (but not too complicated) UIs first in plain C++, perhaps on your workstation, avoiding Qt Creator, to understand how the toolkit works at the code level.  It did that for me, at least.  Then again, I have always used whatever time I needed to truly grok the thing, not respecting any deadlines others may have given me...

[Simon]

I can definitely relate to the frustration (even though not to the claim that this makes it utter shite), but I'd suggest doing some real (but not too complicated) UIs first in plain C++, perhaps on your workstation, avoiding Qt Creator, to understand how the toolkit works at the code level.  It did that for me, at least.  Then again, I have always used whatever time I needed to truly grok the thing, not respecting any deadlines others may have given me...

How do you make a UI with just C++? my understanding is that the only way to go graphical is to use a toolkit/library of some kind.

[Karel]

Qt is one of the best if not the best frameworks for desktop stuff. All GUI programming sucks. Qt makes it much easier. Their preprocessor is quite annoying, but it actually enables a lot of functionality that would be hard otherwise. Their documentation is also some of the best I've seen.

No idea how it translates to embedded, especially if you don't want traditional standard-looking windows and typical desktop behavior. I get a feeling, it is not the best option for that case.

Their licensing is also pretty bad.

What exactly is bad about their licensing? Qt is released as opensource with LGPL license,
thus it can be used for free in closed source commercial software. Do you have a problem with that?

[Simon]

What exactly is bad about their licensing? Qt is released as opensource with LGPL license,
thus it can be used for free in closed source commercial software. Do you have a problem with that?

Well can we rely on that statement of yours as legal advise? For someone like me coming at it from the perspective of never dealing with licensing before £4k is probably cheaper than the legal advice I should get and it includes support.

Their small business package is a joke. As the main benefit of the license is the support and that is really all you are paying for. The small business license may sound attractive to a new company but if they are a new company they probably need support, but that is limited to 5 interactions per year.......

[Karel]

What exactly is bad about their licensing? Qt is released as opensource with LGPL license,
thus it can be used for free in closed source commercial software. Do you have a problem with that?

Well can we rely on that statement of yours as legal advise?

https://en.wikipedia.org/w/index.php?title=GNU_Lesser_General_Public_License&useskin=vector

The license allows developers and companies to use and integrate a software component released under
the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft
license to release the source code of their own components.

https://www.gnu.org/licenses/lgpl-3.0.html#license-text

The Qt group says so as well:

https://www.qt.io/download-open-source

So, if the Qt group says that we can use Qt for free in closed source commercial software, who am I to deny it...

[Nominal Animal]

I can definitely relate to the frustration (even though not to the claim that this makes it utter shite), but I'd suggest doing some real (but not too complicated) UIs first in plain C++, perhaps on your workstation, avoiding Qt Creator, to understand how the toolkit works at the code level.  It did that for me, at least.  Then again, I have always used whatever time I needed to truly grok the thing, not respecting any deadlines others may have given me...

How do you make a UI with just C++? my understanding is that the only way to go graphical is to use a toolkit/library of some kind.

No, I mean you don't use the Qt Creator to generate the C++ code for the user interface; you only use the XML or QML description –– the XML or QML files –– of the interface, and write the necessary C++ code using Qt libraries yourself.

Well can we rely on that statement of [Karel's] as legal advise?

LGPL 2.1 and later are explicit in that dynamically linking the library to a proprietary closed-source code does not create a derivative work.
That is, when you use dynamic linking, and the user can replace the LGPL'd libraries, the situation is absolutely clear: you are explicitly allowed to use LGPL'd libraries from proprietary closed-source code.

This means that for a Linux-based appliance, you do need to provide the users a way to replace the libraries, but you do not need to provide any sources for your own proprietary binaries.

Using LGPL'd binaries in encrypted/protected firmware binaries the end user cannot modify, or statically linking LGPL'd binaries with proprietary closed-source code, is a different matter.  The issue is the definition of "work that uses the library", with respect to copyright law.  For the dynamic linking case, when the end user can replace the library, the situation is utterly clear.  For the statically linked "lumped" model where the user cannot replace the library, the situation is iffy.  That is all.


Some background is in order.  Qt Group Plc began as Trolltech in 1994 in Norway, but is now a Finnish company.  The founders started writing Qt in 1991.  They fundamentally understand GPL and LGPL licensing and the importance of GPL and LGPL to their business, especially through KDE, K Desktop Environment.  In the last five years or so, they've also made licensing much clearer on their website; before that, there was some marketing-wank trying to scare developers to get a commercial license, but it's much better nowadays.

If your appliance documentation prominently tells that Qt is used for the UI under the LGPL license, and includes the exact versions and links to sources used, preferably with a way to rebuild the libraries from scratch (unless you use qt.io-provided binaries), and you abide by LGPL as I outlined above so users can replace those libraries, Qt Group Plc and Qt developers will be happy with you.

One major issue some appliance developers have is that they want to encrypt the firmware so that end users cannot modify it.  This is uncertain legal domain, and I claim it is incompatible with GPL (so Linux is out) and may be incompatible with LGPL.  If you do encrypt the firmware, you need to provide the user with the encryption key so users can regenerate the firmware from GPL'd and LGPL'd sources and your proprietary binary blobs, so you'd have to use an unique key per appliance.  With anything GPL-based like Linux, the fundamental idea is that the user owns the device, and must be allowed to do with it as they please, with only redistribution/copying restricted by the copyright laws and licensing.  LGPL amends that in the sense that it allows proprietary code to use the library, but only when the user is in full control of the LGPL'd library.  When you understand this viewpoint, you'll see that everything in GPL and LGPL suddenly makes sense.

[JPortici]

So, is it really worth it?

Yes,
all the problems you describe are bizarre. I second the recommendation of getting a book, as i was really struggling in the beginning. Luckily i had the beaglebone book that had examples in Qt for the GUI part that helped me getting started (but i wouldn't recommend it now, Qt 5 is on life support .. and that was maybe even using Qt 4.)

Resource system is pretty easy to understand: Add the file to a qrc file (using the resource editor maybe, right click on qrc file in the IDE, select resource editor instead of plain text) and then reference it in the project using its path. Bonus is that you get the resources copied over, as they live inside the bynary file. Minus that you get the resources inside the binary file (adds to size, can't change without recompiling)

There are things missing in the docs (mainly WTF do i do for styling? where the f are the references for the various elements you have to use in the style?) that are explained better in the forum, or in the wiki. But look at almost any other API Reference out there, Qt is probably the best.

But the key is to keep things simple. If you think something is getting too convoluted, there is always another, simpler way to do it

[Jeroen3]

Is Qt this bad or is it something only to be used by the experienced?

You're probably frustrated by your own lack of knowledge about software architecture. GUI software is hard.
But Qt really is one of the best gui frameworks around imho. At least you don't have to worry about pixels when laying out a form....
I'm currently trying something in Winforms with C#, and Qt really is decades ahead.

However, Qt does rely on the programmer having decent knowledge on how to apply design patterns, recognize the patterns Qt uses and fit the classes in their design.
I recommend this to get started: https://refactoring.guru/design-patterns

_{There are also many web-based gui solutions around. Qt also has one. Go with care. Web based is extremely fragile and wild west.}

[radiolistener]

How do you make a UI with just C++? my understanding is that the only way to go graphical is to use a toolkit/library of some kind.

Here is example with simple window and button OK:

Code: [Select]

// gcc -o test test.c -Wall -lX11
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xos.h>
#include <stdio.h>
#include <stdbool.h>


int main() {
    Display* display;
    Window window;
    XEvent event;
    int screen;

    display = XOpenDisplay(NULL);
    if (display == NULL) {
        fprintf(stderr, "Cannot open display\n");;
        return 1;
    }
   
    screen = DefaultScreen(display);
    window = XCreateSimpleWindow(display, RootWindow(display, screen), 100, 100, 300, 200, 1,
                                 BlackPixel(display, screen), WhitePixel(display, screen));
    XSelectInput(display, window, ExposureMask | ButtonPressMask);
    XMapWindow(display, window);
    GC gc = XCreateGC(display, window, 0, NULL);
    XSetForeground(display, gc, BlackPixel(display, screen));
   
    while (true) {
        XNextEvent(display, &event);
       
        if (event.type == Expose) {
            XDrawRectangle(display, window, gc, 100, 80, 100, 40);
            XDrawString(display, window, gc, 130, 105, "OK", 2);
        } else if (event.type == ButtonPress) {
            int x = event.xbutton.x;
            int y = event.xbutton.y;
            if (x >= 100 && x <= 200 && y >= 80 && y <= 120) {
                break;
            }
        }
    }
   
    XFreeGC(display, gc);
    XDestroyWindow(display, window);
    XCloseDisplay(display);
    return 0;
}


[Jeroen3]

I can definitely relate to the frustration (even though not to the claim that this makes it utter shite), but I'd suggest doing some real (but not too complicated) UIs first in plain C++, perhaps on your workstation, avoiding Qt Creator, to understand how the toolkit works at the code level.  It did that for me, at least.  Then again, I have always used whatever time I needed to truly grok the thing, not respecting any deadlines others may have given me...

How do you make a UI with just C++? my understanding is that the only way to go graphical is to use a toolkit/library of some kind.

You need the framework because it's an enormous amount of work to do layout and stuff.
eg: https://github.com/nicbarker/clay