On Wed, Mar 12, 2003 at 07:58:58AM -0600, Jon Nelson wrote:
> > > old = gtk.events_pending
> > > def duh(*args):
> > > return 0
> > > gtk.events_pending = duh
> > > self.do_real_work_with_data_read_from_file(data_read_from_file)
> > > gtk.events_pending = old
> > >
> > > for this problem?
> > >
> > > The reason this appears necessary is explained below.
> > > *Somebody* has a better solution, I'm sure of it!
> >
> > This seems really silly.
> > If you're gonna f up events_pending in this way, then that means you are
> > not going to ever pump the gtk event queue. If you really don't need to
> > call mainiteration, then why don't you just remove the whole
> > while gtk.events_pending(): gtk.mainiteration nonsense.
>
> Actually, it means that gtk.events_pending() will always return 0 while
> the function self.do_real_work_with_data_read_from_file is being run.
This is what confuses me. I don't understand how using a flag won't
avoid this ugliness. See:
check_events = 1
def my_callback(self, *args):
self.check_events = 0
self.do_real_work_with_data_read_from_file(data_read_from_file)
self.check_events = 1
def do_real_work_with_data_read_from_file(self, data):
# ...
if self.check_events and gtk.events_pending():
# do stuff here
# ...
Why doesn't this work if adding a stub gtk.events_pending *does*? Is
gtk.events_pending being called elsewhere?
> > Now the problem that you are running into is that select()/poll() and
> > the glib FD polling mechanism are all level sensitive. When you
> > input_add your fd, you are going to be notified whenever a read will not
> > block. This means that if the OS had buffered 200 bytes, you were
> > notified and only read 100 bytes, you will get the event again. Realize,
> > that this is basically a good design, don't fight it.
>
> I am quite aware of how select looping works. If you had read the whole
> thread (which it's clear you haven't) you would know that there is a
C'mon, let's be nice among friends :-) It's still Wednesday!
Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
