> From: Thiago Macieira <thiago.macie...@intel.com> > To: development@qt-project.org > Cc: > Sent: Tuesday, February 26, 2013 10:46 AM > Subject: Re: [Development] Evolving Qt's multithreading API > > On terça-feira, 26 de fevereiro de 2013 07.03.37, BRM wrote: >> Personally, I can easily seem myself replacing my current QThread usages >> with this functionality; but I'd want to be able to receive both >> start/finished signals (for logging purposes) and be able to interact with >> the QThread object - so the Trampoline object would need to provide an >> interface by which to access the internal QThread, or be a pass thru for >> signals/slots of the QThread. > > Why? Why do you need access to the QThread object? Please don't answer the > started / finshed signals -- those will be provided.
Querying the status of the thread, and waiting for termination - e.g. QThread::wait(); or connecting a signal to tell it to quit. Having a minimal API is great for creating it; but you may still need access to the other functions provided by the QThread API. Either direct access or a pass-thru API would suffice; but it's probably a lot easier to have: QThread* Trampoline::getThread() const; than to do all the signals/slots/etc in the Trampoline object. $0.02 Ben _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
