This sounds like a great idea :] So, as a consistency is a prime property of every cake, in case of sockets this could be pair of:
QAbstractEventDispatcher::enableSocketNotifier() QAbstractEventDispatcher::disableSocketNotifier() I did not notice if unregisterTimer() and registerTimer() are also called so often but their non-destructive switching could also come in handy. Do you think that changing current QSocketNotifier::setEnabled( bool ) behaviour to actually enable / disable notifiers is a good idea? I don't know much about Qt at this level or how much of current code depends on them actually registering and deregistering. Also, does QSocketNotifier 'know' when it is supposed to release underlying socket? Could registering and deregistering be moved entirely to its constructor and destructor? I don't know how QAbstractEventDispatcher interops with QTimer, I will try to research it a bit more. pon., 30 gru 2019 o 01:19 Thiago Macieira <[email protected]> napisał(a): > The better way would be to have a new virtual in QAED that allows turning > on > and off socket notifiers, timers and Windows events without completely > unregistering them, then change QTimer, QSocketNotifier and > QWinEventNotifier > to use them. > > Qt 6 work, of course, but we're working on Qt 6 right now. So this is the > perfect time. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > _______________________________________________ > Interest mailing list > [email protected] > https://lists.qt-project.org/listinfo/interest >
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
