Hacker News Reader

Comment by thamer | Hacker News Reader

I've written a fair share of GUI apps in C++ on multiple platforms, starting with Win32 API and MFC on Windows and later Qt on Linux. The way you write applications with these frameworks is different enough to have a significant impact on the structure and design of the UI layer.

I don't have any suggestions for how to build such a framework, but I would encourage you to play around with a few existing frameworks to see how they are designed, what you like about them, and what ideas to avoid.

For just one example, see the difference between managing the event loop entirely by hand with Win32[1] and using "signals and slots" in Qt[2]. There is a lot more to UI frameworks than this, and they vary on many more aspects.

- [1] https://docs.microsoft.com/en-us/windows/win32/winmsg/using-...

- [2] https://doc.qt.io/qt-5/signalsandslots.html

View on HN

Thanks! I had a look at signals and slots. Is this similar to Smalltalk's idea of objects sending messages to each other? Like messages they don't know about can be ignored, or something like that (I only watched Alan Kay's videos on this topic, never programmed in Smalltalk myself). If I'm not mistaken, Objective-C had something similar and was also successful for UI, so maybe message passing mechanism is something to explore more…

With Qt you don't really have to deal with unexpected messages. A signal is triggered by an event, like a button click or a slider value changing, a checkbox being toggled, this kind of thing. A slot is just a place to receive it, it's a regular function or method with a compatible signature for the kind of event it's meant to process. There are no unexpected calls because you have to explicitly connect a signal to a slot, something like:

    QObject::connect(&button, &QPushButton::clicked,
                     &mainWindowController, &MainWindowController::onButtonClicked);

If no slot is connected, the signal just doesn't go anywhere.

Something that's special with Qt is that signals and slots are declared in the class using custom syntax, e.g.

    slots:
        void onValueChanged(int value);
    signals:
        void valueChanged(int newValue);

Yes here "signals:" and "slots:" look like the same kind of keyword as "public:" or "private:" in a class declaration, even though internally they're #defined as "public:" and "/**/" respectively.

Qt makes use of a tool called MOC – the Meta Object Compiler – to generate code for signals and slots. It's not a pre-processor but a code generator, which has to run before you can actually compile the code. I think you could probably implement a similar system of event subscriptions without this additional code generation step.

See this page for details: https://woboq.com/blog/how-qt-signals-slots-work.html

signals and slots are just an anonymous callback system. There's no more (or less) magic going on. Anonymous? That means that the thing initiating the callback has no clue what the objects are that will execute callbacks.

Gtkmm, or rather its dependent library libsigc++, does not require a separate build step like MOC, it can handle signals and slots "natively" because it used a more modern version of C++. Qt required MOC when it was first written, and they never moved away from it, despite the language having moved on to allow the required functionality all by itself.

Reply on news.ycombinator.com