Show HN: Crash course in Qt for C++ developers – a blog post series

27 points by AlexFagrell 6 years ago

Hi guys,

Two days ago I published the fourth post in the series and thought it would now be a good time to look for additional feedback here on Hacker News.

The aim of the series (as mentioned in the first post) is to inspire more people to start using Qt. My ambition is to answer the following questions "what is the gist of Qt?"; "what is the 20% that you need to know to develop 80% of the application?"; "what are the perhaps unknown unknowns?". In other words, I'm just covering basics: enough to understand the concepts and where to find additional information should you need it.

Do you agree with the direction of the series so far? Here is the link to the first post:

https://www.cleanqt.io/blog/crash-course-in-qt-for-c%2B%2B-d...

I appreciate your time and would be very happy if you had any feedback.

chaoz_ 6 years ago

I really like the idea. IMO, Qt makes C++ suitable for wide variety of applications.

I learned Qt by reading the source code of default QtCreator applications (like Rich Text Viewer). After you know about SIGNAL/SLOT architecture and pImpl idea you can pretty easily derive it from well-written code. It will also teach you good practices! It was the most efficient method for me and many of my friends.

This way your posts will really look like the "course" and not like "documentation + my comments".

Keep it up!

joezydeco 6 years ago

When I walk people through Qt, I usually start with the QObject/QWidget class setup, show some basic UI elements, create a "Hello World" QApplication, then walk into signals and slots.

The event system is usually something a neophyte Qt programmer hardly ever touches. I don't know if I would lead off with that.

(psst..also: blog posts really shouldn't go under Show HN. Check the rules)

  • AlexFagrell 6 years ago

    Hey there! Thanks, great comment. I'm considering rearranging the topics when it's finished.

    My thinking was that the event loop is one of the first thing that you'll encounter, i.e. app.exec() in main, when using Qt. The fact that the flow of the app is event-driven is important to understand when working with a GUI toolkit and thought it would be good to introduce early on (even though you rarely use the actual event system itself). Perhaps not as a first topic though.

    Yeah, I realised that it shouldn't be Shown HN, but can't find a way to edit it, thanks.

    Appreciate the feedback, cheers!

    • geezerjay 6 years ago

      > My thinking was that the event loop is one of the first thing that you'll encounter, i.e. app.exec() in main, when using Qt.

      Technically that's true, but as the event loop runs under the hood then the event loop doesn't assume a prominent role in Qt's mental model.

      • joezydeco 6 years ago

        Yeah, geezerjay has it right. For a new programmer trying to get a "crash course" in Qt, app.exec() is a black box you don't really need to mess with.

        You can explain that it drives all the mouse, keyboard, and QTimer signals when you begin to implement the event slots on your widgets, but as far as getting an app to run it's a matter of calling app.exec() and leaving it alone.

        • AlexFagrell 6 years ago

          Thanks again! I agree with you!

      • AlexFagrell 6 years ago

        Thanks, very true. Several people have pointed this out so I'm convinced I'll have to rearrange the order. Perhaps just start with a simple example and move the event loop/handling after Widgets/QML. I believe I'll also have to split Widgets and QML into two separate posts as those are big subjects.

        • geezerjay 6 years ago

          Just to complement my comment on Qt's event system, one place where it does play a central role in Qt's mental model is in Qt's concurrency framework. When covering that subject, the event loop and the different connection types are fundamental to understand how QObjects automagically communicate between themselves with Qt's signal-slots framework even when residing in different threads, or how Qt supports concurrency without requiring stuff to run on a separate thread.