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

[Simon]

I'll look into widgets.

[Simon]

Although at this point is there any advantage to Qt widgets over say FLTK?

[Nominal Animal]

If you have a simple example case in mind –– say, like my Python + Qt + serial communications to an Arduino example I linked to ––, you could always suggest something.  When you've worked with a tool for a longer time, it is difficult to devise a good "tutorial" case.

I suspect that if someone still early in the learning curve were to suggest what kind of an example project they'd like to see, we might be able to come up with a good one together.  Just sayin'.

[JPortici]

Although at this point is there any advantage to Qt widgets over say FLTK?

Qt(6) takes care of very annoying things like DPI and per-screen DPI in a way completely transparent to the user. And many other simillar nuances that guarantee a consistent experience across Devices and OSes. Most frameworks completely suck for high dpi screens, android solves it by using "dip" units and translating them to pixels internally, but when it comes to the equivalent device independent text height... well, mantaining a consistent look in android, or even iOS for that matter, is impossible. Apple/google are trying really hard to get there.
Multithreading is IMHO simpler than other threading libraries and platform specific details are taken care of.
It guides you to use a particular subset of C++ that is easier to tame IMHO

I honestly don't know where you are picking up they want you to use QML and QtQuick, if anything in the forum they are suggesting they want to get rid of them, especially QML, which can be a security nightmare according to some of the docs, but they are bound to keep some customers happy. I wonder if we'll see QML in Qt 7

[Jeroen3]

I've not used QUiLoader

I've used it since Qt 4.  By default, if you name your slots (signal handlers) in your main class as on_ObjectName_SignalName, it will automatically connect the signals to your handlers via QMetaObject::connectSlotsByName.

The same works for Python Qt, too.  See this (using this) for a Python + Qt + XML Ui file example.

Yeah it does this. Careful though, implicit stuff like this breaks your head when it somehow doesn't.

Sometime ago they also introduced explicit connecting (typesafe) so you get compile errors when the function signatures don't match. Much better!

Code: [Select]

    QObject::connect(&a, &Counter::valueChanged,
                     &b, &Counter::setValue);


[Simon]

Well my current example would be a custom CAN bus data interpreter, read data off the CAN bus and put it on the screen in ways that make sense. Graphs, readouts, depending on the particular value. A dashboard I guess but with more detailed textual information for some stuff as you can't plot everything no would you want to.

[Simon]

I honestly don't know where you are picking up they want you to use QML and QtQuick, if anything in the forum they are suggesting they want to get rid of them, especially QML, which can be a security nightmare according to some of the docs, but they are bound to keep some customers happy. I wonder if we'll see QML in Qt 7

Just read the stuff here: https://doc.qt.io/qt-6/topics-ui.html especially in the comparison table it makes it sound like there is stuff only QML does. In forums I have read people saying that they are pushing QML because it is JavaScript and there are more JavaScript people around than C++ programmers so it's cheaper to hire them and give them something they can do.

[Jeroen3]

In correct architecture, the UI should be decoupled from the core code so you can run whatever UI. Or none at all, for testing.

With Qt Widgets you can have some of the core code, if also made with Qt, such as models, seep into the UI code. You can also do it the other way around and snake your core code in the UI code.... (avoid this please)

With web-stuff you have to create duplicate objects in the other language with translation code because it needs to sent to a browser over http(s).

It has advantages, such as the ability for a polished ui (made by web frontend people) with fancy graphics or acceleration (opengl) for "Fluid animated UIs".
It has disadvantages, such as that you have two distinct tech stacks.

Do not underestimate how much time you're spending centering divs.

[JPortici]

I honestly don't know where you are picking up they want you to use QML and QtQuick, if anything in the forum they are suggesting they want to get rid of them, especially QML, which can be a security nightmare according to some of the docs, but they are bound to keep some customers happy. I wonder if we'll see QML in Qt 7

Just read the stuff here: https://doc.qt.io/qt-6/topics-ui.html especially in the comparison table it makes it sound like there is stuff only QML does. In forums I have read people saying that they are pushing QML because it is JavaScript and there are more JavaScript people around than C++ programmers so it's cheaper to hire them and give them something they can do.

really? It's not the impression i had. Guess i was reading different threads
And whatever QML brings to the table, i don't care about (gestures, animations, ...)

at least not for my pc software (the animations I implement are fade in/out or page scrolling, nothing that can't be done in C++)

Re: your endless canbus quest, I did that of course, canbus is nothing special on windows. My interface is from KVaser so i just added the dll and header files to the project. Include the header and call the functions. On linux, i don't know. Probably you need to use the QSerialBus classes? Also, don't know if you need to do anything special if you have an interface supported by QSerialBus

This is one of the few projects i haven't migrated to CMake as it's feature freeze right now. It's still using qmake (and it's easier to add library files there, as you can use the context menu)
You can start single threaded then move the CAN stuff to a different thread. To get the data (available interfaces, data from the bus, ...) send a signal from the CAN stuff, a slot in the GUI element will receive the data and update the GUI. To set the data (select the interface, start, stop, configure, ...) you do the opposite, a signal from the GUI element is connected to a slot in the CAN stuff object.

the .pro file looks like this:

Code: [Select]

QT       += core gui

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

CONFIG += c++17

# You can make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0

SOURCES += \
    all my sources

HEADERS += \
    all my other headers
    kvaser/canevt.h \
    kvaser/canlib.h \
    kvaser/canstat.h \
    kvaser/obsolete.h \
    kvaser/predef.h \

FORMS += \
    mainwindow.ui \
    obdxconfigurationdialog.ui

# Default rules for deployment.
qnx: target.path = /tmp/$${TARGET}/bin
else: unix:!android: target.path = /opt/$${TARGET}/bin
!isEmpty(target.path): INSTALLS += target

DISTFILES += \
  kvaser/canlib32.dll \
  kvaser/canlib32.lib

win32: LIBS += -L$$PWD/kvaser/ -lcanlib32

INCLUDEPATH += $$PWD/kvaser
DEPENDPATH += $$PWD/kvaser

win32:!win32-g++: PRE_TARGETDEPS += $$PWD/kvaser/canlib32.lib
#else:win32-g++: PRE_TARGETDEPS += $$PWD/kvaser/libcanlib32.a

For example, to get the list of connected interfaces

Code: [Select]

MainWindow::~MainWindow() {
  if (canHandle >= 0) {
    canBusOff(canHandle);
    canClose(canHandle);
  }
  delete ui;
}

void MainWindow::loadCanInterfaceData(void) {
  canInitializeLibrary();

  //Initialize Data
  canHandle = -1;

  int nChannels;
  canStatus status;

  ui->cbCanInterfacesList->clear();

  status = canGetNumberOfChannels(&nChannels);
  if (status == canStatus::canOK) {
    if (nChannels > 0) {
      for (int idx=0; idx<nChannels; idx++) {
        int deviceChannel;
        char deviceName[255];

        canGetChannelData(idx, canCHANNELDATA_CHAN_NO_ON_CARD, &deviceChannel, sizeof(deviceChannel));
        canGetChannelData(idx, canCHANNELDATA_DEVDESCR_ASCII, deviceName, sizeof(deviceName));

        if (!QString(deviceName).contains("Virtual", Qt::CaseInsensitive)) {
          ui->cbCanInterfacesList->addItem(QString("%1 - %2 Ch %3").arg(idx+1).arg(deviceName).arg(deviceChannel+1), idx);
        }
      }
    }
  }

  if (ui->cbCanInterfacesList->count() > 0) {
    ui->cbCanInterfacesList->setEnabled(true);
    ui->pbSelectCanInterface->setEnabled(true);
  }
  else {
    ui->cbCanInterfacesList->setEnabled(false);
    ui->pbSelectCanInterface->setEnabled(false);
  }
}
(but here i didn't do more than follow the examples that kvaser provided and adapted them to qt)

[Simon]

Re: your endless canbus quest, I did that of course, canbus is nothing special on windows. My interface is from KVaser so i just added the dll and header files to the project. Include the header and call the functions. On linux, i don't know. Probably you need to use the QSerialBus classes? Also, don't know if you need to do anything special if you have an interface supported by QSerialBus

it's not a case of an endless quest, I have not looked at the CAN bus side of things much other than to establish that in linux at least it is natively supported. One of the microchip CAN controllers on SPI has a driver for it in linux so I don't have to worry and have parked that there. The bigger aspect to anything I would want to do it putting stuff on the screen. Once those two are accomplished then I can move on to adding other functionality.

[Nominal Animal]

You'll want to run your I/O and parser in a separate thread anyway –– UI thread is event-driven and "owned" by the UI toolkit; not the place you want to do any work or require low latencies ––, so I'd suggest you start by writing text-mode CANbus parser first.

[Simon]

Yes, all that in time. If I don't have fancy graphics, there will be no product  .

[Jeroen3]

  Kvaser is very easy to implement in your own software. Their platform is very stable.
There is a QCanBus, but it does not support kvaser right now. I don't think it's worth it porting it yourself, there don't seen to be other modules that depend on it.

Anyway, at the end it's just message objects and observer pattern.

Let me know if you have any questions, all our qt based internal tooling uses kvaser leafs.

[Simon]

I have a kvaser adapter already so will use that in the first instance.

[Nominal Animal]

Yeah [QMetaObject::connectSlotsByName] does this. Careful though, implicit stuff like this breaks your head when it somehow doesn't.

Yep, that's why I prefer to do my own connecting, using external information instead of implicit handler names.

Typesafe (functor/function pointer) format as you showed is much better, definitely; I use it whenever possible.  When using it with external UI files, one can look up the objects by name, but use the base class reference for the signal or slot involved, so that the UI can use any compatible subclass.

To work all that out, I do prefer to create mock-ups in Inkscape or even HTML/browser, after I have implemented the lower level functionality so I know for a fact which information I need, want, and may wish to display and let the user interact with.  The base functionality is much more important to me than the UI.  I often use Python for the UI because that way UI enhancements and modifications don't require recompiling, and Python is fast enough for this.  All the proprietary logic is then in native binary libraries dynamically loaded by Python and interfaced using Python ctypes built-in module with minimal Python glue; although it is much easier to interface library code written in C than that written in C++, I believe.  Plus, that way I can license the Python UI part more permissively, so users who want can freely enhance the UI (including redistribute the Python parts, not including the proprietary libraries it needs), while keeping my proprietary bits private.

[Geoff-AU]

I use the Qt Creator to give me the QtWidget-based XML .ui file that I load/build with QUiLoader, part of the UiTools Qt module.

<snip>

Unlike what Jeroen3 implied, you do not need to let Qt Creator create the C++ code to instantiate the UI (so that double-clicking on the widget takes you to the generated C++ code handling the events related to that widget).  That was exactly what I was recommending against.

This is what I'm doing.  Qt Creator to generate a .ui file and then a Python script that instantiates the UI.  Picking up the functional hooks for events and so on was fairly intuitive for me, luckily.  It's a very good separation of graphical UI creation and programming to do it this way.

If I don't have fancy graphics, there will be no product  .

This is where I feel the limitation is.  Most controls available natively in Qt Creator look dated (25+ years old, classic buttons and text fields and numerical up/down etc). "LCD" value displays look particularly bad.  There may be more modern options, I need to look.  I used pyQtGraph because my app is Python. Charting/plotting with this library performs well even on a Raspberry Pi and looks beautiful.

[SiliconWizard]

You should use Pascal and Lazarus.