On Wed, 12 Mar 2003, Christian Reis wrote:

> 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.

Yes.  eventually the function do_real_work_with_data_read_from_file (I
am getting tired of typing that) *does* call:

while gtk.events_pending():
  gtk.mainiteration()

It's necessary for various reasons, not the least of which is a simple
progress bar.

> > 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!

That's true, I was harsh. I apologize for being harsh.  I don't like my
hard-fought solutions being called "nonsense".

Thanks Christian!

--
"Never try to write to ROM - it wastes your time and annoys the ROM."

Jon Nelson <[EMAIL PROTECTED]>
C and Python Code Gardener
_______________________________________________
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Reply via email to