Re: [gtk-list] Re: Multiple main loops
- From: pavel <pavel klebanov ne mediaone net>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Multiple main loops
- Date: Fri, 18 Jun 1999 22:20:32 -0400 (EDT)
I'm not sure if using the readline lib changes much but I once wrote a
command driven gtk app by using:
gdk_input_add (fileno(stdin), DK_INPUT_READ,
(GdkInputFunction) myfunc, NULL);
Why won't this work for you?
On Fri, 18 Jun 1999, Scott Dattalo wrote:
>
>
> On 18 Jun 1999, Owen Taylor wrote:
>
> > Scott Dattalo <sdattalo@unix.sri.com> writes:
> >
> > > I'm writing a gui wrapper around my currently command-line-interface only
> > > program and am having a problem with more than one library wanting to be
> > > the 'main loop'. Specifically, I'm using the readline library for the CLI
> > > and then I'm also using gtk for the gui api. Each requires complete
> > > control of the process. I thought I had solved this problem with pthreads.
> > > In other words, I have a main pthread that spawns two child threads and
> > > runs the gtk loop in one and the readline loop in the other. It sorta
> > > works. However, 1) It always SEGVs when it exits and 2) It occasional gets
> > > X, gdk, and/or shmem errors.
> >
> > Instead of trying to answer the questions about threads,
> > etc, let me point out that you can make readline()
> > use the GTK+ main loop.
> >
> > See rl_callback_handler_install() in the readline documentation.
>
> Correct me if I'm wrong, but... doesn't this imply that a gtk widget is
> receiving keys and redirecting them to readline via callback interface? In
> my case, the readline library is receiving it's input from stdin (from the
> terminal in which the processs was invoked). In other words, for now the
> textual base of my program runs in an xterm (actually Eterm :)) while the
> graphical portion runs in a GtkWidget widget (that contains other
> widgets...). The keypress events for the various GtkWidgets are
> automagically routed to the proper places. When the terminal receives
> focus, then the keypress events are directed to readline (via stdin).
> Hence, to make the call back process work, I would have to be able to
> capture the keypress events for the xterm. Is this correct? And if so, the
> next obvious question is how?
>
>
> On Fri, 18 Jun 1999, Paul Barton-Davis wrote:
> > >In other words, I have a main pthread that spawns two child threads and
> > >runs the gtk loop in one and the readline loop in the other. It sorta
> > >works. However, 1) It always SEGVs when it exits and 2) It occasional
> gets
> > >X, gdk, and/or shmem errors.
> > >
> > >
> > >This subject was brought up a few weeks ago, but unfortunately the
> archive
> > >is currently down...
> >
> > are you making GTK calls from the non-GTK thread ? you can't do this
> > safely unless you wrap the GTK calls in GTK_THREAD_{ENTER,LEAVE} or
> something
> > like that.
>
> One of the reasons I chose threads over forking is so I wouldn't have to
> deal with shared memory details. So to answer your question, yes I'm
> making gtk calls from non-gtk threads (and liberally exchanging data
> between the two) and no I'm not using the GTK_THREAD macros. I will look
> into this, however I'd like to do away with threads and use the
> signals-only-approach if it's possible. Thanks.
>
> Scott
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]