4 ms·

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

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 8y 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.
- AlexFagrell 8y 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 8y 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.
- joezydeco 8y 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 8y ago
    Thanks again! I agree with you!

geezerjay 8y 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.

AlexFagrell 8y 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 8y 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.
joezydeco 8y 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 8y ago
  Thanks again! I agree with you!