Some real great videos out there. I come from many years of embedded programming (mainly with C, C++ and assembly), and over the years I made my way up all the way to cloud and back-end programming. Been wathcing some of your videos, and some great effort you've put in there, so well done for this contribution! One question though on this video: Demonstrating on which thread the code of function run() is running, the connect function inside run() function worked fine and correctly when using QThread without needing to use Qt::DirectConnection, but why did it not work when using QThreadPool and we had to explicitly mention Qt::DirectConnection? Appreciate your repsonse here. Thank you.
Thank you for your great videos. One question about using QtConcurrent. Is it me, as in my interpretation, or the main thread gets stuck until worker->run finishes? The message "Testing..." only shows up after all the thread work is finished, on previous examples that message showed up even before the worker construction message. Forgett it! I just figured it out, its only the "testConcurrent" function that, naturally, waits for the worker->run statement to finish. The "main thread" finished almost immediaty as expected.
I think the way you do it now is fine, explaining the QtCore elements first in console is easy to grab without having to deal with the GUI widgets. THEN explain the GUI widgets incorparating all the essential Core stuff. Also means ppl can make their own easy projects to mess around with easily enough too. GUIs have their own stumbling blocks that are best tackled once you have the basics down pat. Like understanding what threads are and signal and slots (signals and slots I think is the key to Qt once you really understand them you can really use Qt)
So QScopedPointer is similar to std::unique_ptr? What's the advantage over just declaring a local variable, other than that it can help to avoid stack overflows?
I'm really struggling to understand where I would create a thread that interacts with the UART and how that thread would interact with the UI thread. Do I do that in main.cpp or in mainwindow.cpp? If I try to talk to the UART from main, none of my data is transmitted until after w.show gets called. Do you have an example of this? I bought your udemy courses in hopes I could find an example but I don't really have time to watch all the videos. Seems like this should be simple but I am a Cortex M C programmer and this stuff is radically different. Every example I find is either far too simple or far too complicated. Why is a single thread interacting with the UI thread not a more common example?
While the command line is very interesting and useful, Qt is famous for its widgets. You should first explain how the actual program should work in the background and then explain widgets, but there's nothing wrong with just doing it in a mixed way. Its more important to make the code good (with threads etc..) and the GUI will be better. Like you just showed, without threading you really run into some issues using widgets.
