Forum: Ruby QT Ruby odd focus behavior

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Christopher T. (Guest)
on 2007-03-08 06:27
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 G. (Guest)
on 2007-03-08 12:55
(Received via mailing list)
On Mar 8, 5:27 pm, Christopher T. <removed_email_address@domain.invalid> wrote:
> 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?
>
> --
> Posted viahttp://www.ruby-forum.com/.

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 T. (Guest)
on 2007-03-10 06:57
> 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 W. (Guest)
on 2007-03-11 07:12
(Received via mailing list)
Christopher T. wrote:
> 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 T. (Guest)
on 2007-03-11 22:20
> 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 ;-)
(Guest)
on 2007-03-11 22:30
(Received via mailing list)
On Mar 11, 8:20 pm, Christopher T. <removed_email_address@domain.invalid> wrote:
> For this project, I might assume that it won't be a problem because
> there won't be anybody sharing with themselves anyway ;-)
>
> --
> Posted viahttp://www.ruby-forum.com/.
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 T. (Guest)
on 2007-03-14 23:02
>> --
>> Posted viahttp://www.ruby-forum.com/.
> 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!
This topic is locked and can not be replied to.