Quote:
Originally Posted by meme
Ok - the good news is this seems to fix the serialization of sending books to the device.  |
Excellent.
Quote:
One problem is that I am displaying a dialog in my job_completed function that is causing calibre to crash. The issue is that within the job I instantiate a class (for messages) using the gui passed into the job - and I return that instantiated class and try to call its display method. calibre promptly warns me about pixmaps in a non-gui thread, missing parents, etc. and dies. So I need to re-arrange this code to only return the message strings to the job's parent and use the gui in the job's parent to present the dialog. Ah, if I had only coded it properly to begin with  (Interesting that this didn't fall over with 0.8.5, just with the modified source)
|
It sounds like you have not wrapped your done function with FunctionDispatcher().
The big difference in the new code is that the done functions are now called on the job thread, not the GUI thread. For this reason it is *required* that they be wrapped with Dispatcher() or FunctionDispatcher(), so that the thread switch can happen.
Quote:
|
I guess I can add a check to see if the device is connected before I kick off the job - but it seems to me it should be okay to do this and the job should queue until the device is connected? This behaviour is the same in 0.8.5.
|
I don't see anything in the code that checks for a device connected before running something from the queue. In fact, I think that if a device is disconnected, all queued jobs are flushed. The current code does not start jobs when a device is not connected.