QT Ruby odd focus behavior

[Christopher Tasma]

Hello all,

I was writing a simple 'file sharing' program with QT and ruby. I
noticed when running two clients on one machine for testing some odd
behavior with the focus. When a peer receives a request from and serves
files to another peer, it does so from a file server running in a
separate thread.

I noticed that the programs seem to die when there is no focus on the
main window of the client. As I watch the socket comminication on the
console, I see that I have to move the mouse over the peer who needs to
take the next step before anything will happen. If I make a request
from the other peer, it just sits there waiting for some response. I
have to actaully move over and give focus to the other window before it
will respond. I have to go back and forth like this until all
communication is done.

Any have any ideas on how this would be tied to the windows focus?

 

[Timothy Goddard]

Hello all,

I was writing a simple 'file sharing' program with QT and ruby. I
noticed when running two clients on one machine for testing some odd
behavior with the focus. When a peer receives a request from and serves
files to another peer, it does so from a file server running in a
separate thread.

I noticed that the programs seem to die when there is no focus on the
main window of the client. As I watch the socket comminication on the
console, I see that I have to move the mouse over the peer who needs to
take the next step before anything will happen. If I make a request
from the other peer, it just sits there waiting for some response. I
have to actaully move over and give focus to the other window before it
will respond. I have to go back and forth like this until all
communication is done.

Any have any ideas on how this would be tied to the windows focus?

Do you have explicit callbacks into Ruby to allow Ruby's green threads
to go? Ruby doesn't use operating system threads yet and QtRuby will
not be particularly respectful about letting Ruby run at appropriate
intervals. I'm guessing there are enough callbacks to Ruby code while
the window is in focus for your thread to run happily but the thread
is starved while the Qt window is receiving no external events. You
could fix this by creating a timer which periodically calls
Thread.pass and allows other Ruby threads to run.

 

[Christopher Tasma]

Do you have explicit callbacks into Ruby to allow Ruby's green threads
to go? Ruby doesn't use operating system threads yet and QtRuby will
not be particularly respectful about letting Ruby run at appropriate
intervals.

Thanks for the suggestion, and sorry it took so long to try it out.
There hasn't been much time after work this week to play ;-)

I tried several different things to try and give control to the
interpreter, but I didn't have much luck. The best I got with the
Thread.pass was a non functioning GUI. Any more ideas would be welcome,
otherwise I will try to post what is going wrong if I ever figure it
out.

 

[Jeremy Wells]

Thanks for the suggestion, and sorry it took so long to try it out.
There hasn't been much time after work this week to play ;-)

I tried several different things to try and give control to the
interpreter, but I didn't have much luck. The best I got with the
Thread.pass was a non functioning GUI. Any more ideas would be welcome,
otherwise I will try to post what is going wrong if I ever figure it
out.

This might not be particularly useful, but have you considered
separating the gui code from the actual functional part and having them
run in separate processes? this would fix your issue, and give you the
'feature' of allowing the downloads to continue with no window or have a
different gui.

 

[Christopher Tasma]

This might not be particularly useful, but have you considered
separating the gui code from the actual functional part and having them
run in separate processes? this would fix your issue, and give you the
'feature' of allowing the downloads to continue with no window or have a
different gui.

I've thought about that. I hadn't done anything with ruby and threads
before this, so I got myself into a hole on this one. I think next time
I will have to do like you said, and separate things on a process level.

For this project, I might assume that it won't be a problem because
there won't be anybody sharing with themselves anyway ;-)

 

[richard.j.dale]

I've thought about that. I hadn't done anything with ruby and threads
before this, so I got myself into a hole on this one. I think next time
I will have to do like you said, and separate things on a process level.

For this project, I might assume that it won't be a problem because
there won't be anybody sharing with themselves anyway ;-)

Qt and QtRuby have complete support for networking integrated into the
Qt event loop via classes such as Qt::SocketNotifier, Qt::TcpSocket or
Qt::Ftp, and so you might be better off using them rather than ruby
threads or extra processes. Otherwise, you can set a Qt::Timer to
periodically call a slot and allow the Ruby interpreter to run the
code in the threads as another reply suggested.

-- Richard

 

[Christopher Tasma]

Qt and QtRuby have complete support for networking integrated into the
Qt event loop via classes such as Qt::SocketNotifier, Qt::TcpSocket or
Qt::Ftp, and so you might be better off using them rather than ruby
threads or extra processes. Otherwise, you can set a Qt::Timer to
periodically call a slot and allow the Ruby interpreter to run the
code in the threads as another reply suggested.

-- Richard

Thanks for the ideas!