Ice/Ruby/Qt example

[Andreas Scherer]

Cool! What a nice surprise at the end of the holidays.

After looking at the demos shipped with IceRuby, I decided to push it somewhat further and came up with version 0.1 of QtClient.rb for the "hello" server. Please refer to the attached file for the code; details follow here.

My configuration is OpenSUSE 10.0 with KDE 3.5.5 (kdebase3-3.5.5-17.1, qt3-3.3.6-185.1) and Ruby 1.8.2 (ruby-1.8.2-11.6). First I tried to upgrade to Ruby 1.8.5 as requested by IceRuby, but after I got hung up by kdebindings3-3.5.5-32.1, I decided to relax the requirements by patching config/Make.rules instead.

When IceRuby compiled with Ruby 1.8.2, I modified the local environment appropriately by sourcing the shell file setupIceRuby. Then I merged code and ideas from the Qt/C++ "hello" client and the IceRuby console example, and came up with an initial version of QtClient.rb; this does not (yet) make use of a CallQueue as its C++ twin, but it seems to work just fine. Of course, comments are very much appreciated. Finally I changed the example config.client for the "linux" local host.

Cheers

[Andreas Scherer]

Can someone confirm that the CallQueue mechanism is currently not supportable in IceRubyQt? According to Richard Dale (http://lists.kde.org/?l=kde-bindings&m=112973788316454), Ruby threads can not be used in a QtRuby application (and IceUtil::Thread/Mutex are not available).

Today I tried without success to make QtClient.rb responsive in case of long-running server events. However, as long as I do not join my callThread (aka playerThread or consumerThread) prior to qtapp.exec, the "Hello" button works synchronously. If I invoke callThread.join before qtapp.exec, the program aborts with a deadlock exception (presumably because the Queue runs empty?).

Help and comments are welcome!

[mes]

Hi Andreas,

The Ruby interpreter is blocked for the duration of an Ice invocation. Since the interpreter uses only one native thread, this means that all Ruby threads are blocked until the invocation completes. If the Ruby interpreter ever supports native threads, I expect that we'll add support for asynchronous invocations. Until that time however, it would be difficult to address this limitation, and I doubt we would attempt it without someone to sponsor the effort.

Take care,
- Mark

[Andreas Scherer]

Thanks, Mark.

It's not a pressing issue for me right now, so my initial QtClient.rb will have to stand as a nice proof-of-concept. Note that the updated attachment to my first submission now destroys the communicator; this part got thrown out with the surrounding CallQueue stuff.

Greetings