On Wed, Jan 2, 2019 at 5:55 PM Roland Hughes <rol...@logikalsolutions.com> wrote:
> By then, Qt has abandon them. Yeah, recently I had worked on a couple of projects for one such company (in aviation meteorology). They were "abandoned" for many years because it takes at least minimal effort to actually follow the new releases and support your code, which they did not. And as Qt6 is peeking around the corner, they've finally ported the old code to Qt5 (5.6). I wonder how much time it's going to take them to get from Qt5 to Qt6, perhaps I'll be old and frail by then. Complex programs won't just run by themselves forever if you are not willing to put in the time to support them, don't expect others to do the dirty work for you. Just hoping, and also spreading such expectations, that a library (or a system) is going to guarantee compatibility and at the same time get updates forever is neither realistic, nor is it going to happen, Qt is no exception. I don't know for certain and don't care enough to dig into it again, > but, I believe someone stated at some point that when a parented QObject > was created some of the parents didn't connect the destroyed() signal to > a slot which would remove the child from their list. Removal from the children list is done through an event, not through connecting to QObject::destroyed. The latter is for your convenience. 2) Forget all assumptions about what one can do in threads and how to > create them. > ... > When it comes to threading, don't derive from QThread. Deriving from QThread (or using QThread::create) is perfectly valid if you don't intend to process events. Also everything that's done with an event loop can be done without, it just takes more effort and care. > [...] > Additional obnoxious and irrelevant stuff I have no intent addressing at all.
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
