[mythtv] Ticket #4376: Handle keypresses in the main UI thread (refs#4230 and #4085)

Daniel Kristjansson danielk at cuymedia.net
Tue Jan 1 14:23:01 UTC 2008

On Tue, 2008-01-01 at 07:07 +0000, Andrei Tanas wrote:
> > I'm sure MS Windows allows for multi-threaded GUIapplications, there are
> > probably just some additional limitations. We need to trace the reason for
> > the deadlock when switching from the program guide from LiveTV, and QTimer
> The program guide window is created on a different thread (other than the main UI thread), and when SetFocus (Win32 API) is called from this thread, it hangs (this is 100% reproduceable). The only message loop runs in the main UI thread, the program guide (running in its own thread now) is not capable of processing window messages (one of the first of which would be WM_SETFOCUS, the result of the SetFocus call). That's the way I understand it, if this is not right, somebody please correct me.
> As far as I can tell, the only way to correct it (compatible Windows environment) is to somehow send a signal to the main thread to start the program guide, rather than create it in the tv playback thread directly. Would this be the right way to go? If so, I'll work on a patch for this, I think it's the last "showstopper" issue for Windows frontend.

Sending a message to the Qt event thread to open the window is ok.
But maybe it's possible to make any thread in MS Windows have it's
own event loop? I know we had to do something like that for OS X.
I believe it was in the firewire recorder, which on OS X needs to
be able to respond to events from the OS.

> > can be replaced with something that works on MS Windows. QTimer in
> > particular causes its own thread-safety problems in Linux and OS X anyway.
> I can take a look at the sound muting (during seeks/channel switches) too, but I'm probably not the best person for it. Does sombody else want it?

I could do it, but I have a few other things on my plate for 0.21..

-- Daniel

More information about the mythtv-dev mailing list