Re: [gtk-list] Re: Multiple main loops




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]