[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: qt4 bindings, threads
From:       "=?ISO-8859-1?Q?daniel_=E5kerud?=" <daniel.akerud () gmail ! com>
Date:       2007-12-26 1:05:57
Message-ID: b000da060712251706l304e8adfme8d9ee44b4cf4f8a () mail ! gmail ! com
[Download RAW message or body]


qtruby4 unfortunately lacks QSocketNotifier as well. The Ruby UNIXSocket
class contains a method called read_nonblock which gives me some hope thoug=
h
:-)

/D

On Dec 26, 2007 1:45 AM, daniel =E5kerud <daniel.akerud@gmail.com> wrote:

> Thanks for the quick answer. I'll look up on the non-blocking IO.
>
> I noticed that Qt::Application.exec() stops all Ruby threads as well. So
> no
> go either way.
>
> Anyone knows if there are plans for the future to support threading and
> Qt?
>
> /D
>
> On Dec 26, 2007 1:33 AM, Caleb Tennis <caleb@aei-tech.com> wrote:
>
> >
> > On Dec 25, 2007, at 6:36 PM, daniel =E5kerud wrote:
> >
> > > I couldn't find a mailinglist for the Qt4 Ruby bindings, so I try
> > > here. It
> > > seems the Qt4 Ruby bindings lack Qt::Thread. So how do I create a
> > > Thread? Do
> > > I use Ruby's build-in? I need a thread because I need to read from a
> > > UNIX
> > > domain socket (blocking), and pass the data to the GUI. Thanks for
> > > any help!
> > >
> > >
> >
> > There's no Qt::Thread because Ruby lacks support for native threads
> > (at least, for the moment), so it's not really feasible to implement.
> >
> > The most common workaround is to use a Qt::SocketNotifier to pipe data
> > into the application over a socket so that your GUI isn't blocking
> > while the data is coming in.
> >
> > Caleb
> >
> >
> >
>


[prev in list] [next in list] [prev in thread] [next in thread]