Re: [pygtk] gnome-python in 1.0 pre

1999-02-25 Thread James Henstridge
Yeah I know ... I put it there. Anyhow, you aren't supposed to be looking in that directory right now :) The copy in /pub/GNOME/sources/latest is the same, except for the version number. James Henstridge. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Thu, 25 Feb 1999, D

Re: [pygtk] Exceptions

1999-02-25 Thread James Henstridge
That looks like a good idea in some circumstances. It would make debugging easier, but some may think it makes the actual application less stable. Maybe it is possible to have this as a runtime configurable thing. I should probably look into it further. James Henstridge. -- Email: [EMAIL PROT

Re: [pygtk] I can't make work set_active

1999-02-25 Thread James Henstridge
Do you get the same errors if you call set_active before connecting to its signals? That is what I usually do. The way you have your code, that page of the property box will always look as if it has had changes applied to it, since the call to changed() will always be made. As for the segfault,

[pygtk] gnome-python in 1.0 pre

1999-02-25 Thread David M. Cook
gnome-python has finally made it into the gnome distribution: ftp://gnomeftp.wgn.net/pub/gnome/sources/gnome-1.0-pre Dave Cook To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] I can't make work set_active

1999-02-25 Thread Richard Fish
Well, I can't duplicate your problem with the following code: from gtk import * class Foo(GtkHBox): def __init__(self): GtkHBox.__init__(self) pass def set_active_8(self,*args): print args def create_bit_num(self): bit_num_box = GtkHButtonBox() self.pack_start(bit_num

Re: [pygtk] Hooking into Gtk iterations

1999-02-25 Thread Hrvoje Niksic
Aaron Optimizer Digulla <[EMAIL PROTECTED]> writes: > Quoting Hrvoje Niksic <[EMAIL PROTECTED]>: > > > > > > (does it have anything to do with the threading code?). > > > > I don't think so, no. > > > Yes, that's the same. Threading doesn't work with the current > > > implementation of Gtk becau

Re: [pygtk] Hooking into Gtk iterations

1999-02-25 Thread Aaron Optimizer Digulla
Quoting Hrvoje Niksic <[EMAIL PROTECTED]>: > > > > (does it have anything to do with the threading code?). > > > I don't think so, no. > > Yes, that's the same. Threading doesn't work with the current > > implementation of Gtk because all Python threads are dead as long as > > Gtk waits in its ma

[pygtk] I can't make work set_active

1999-02-25 Thread prueba
I have a really really weird and nasty bug in my aplication with set_active. I instance to RadioButtons and try to set active the one that isn't pressed by default, and my application dumps a core. The worst thing is that I tried to program a simple example where I can show the bug. But the simple

[pygtk] Exceptions

1999-02-25 Thread Ture PĂ„lsson
I thought it would be nice if exceptions could propagate from callbacks, "through" the event loop and out to the top-level python code. The folloing code seems to do the trick. Does it break something else? -- Ture --- gtkmodule.c.~1~ Wed Feb 24 16:43:28 1999 +++ gtkmodule.c Thu Feb 25 16:

Re: [pygtk] Hooking into Gtk iterations

1999-02-25 Thread Hrvoje Niksic
Aaron Optimizer Digulla <[EMAIL PROTECTED]> writes: > The only solution I see is to add a timer: > > def wakeup: > pass > > timeout_add (100, wakeup) I know of this solution and I will not use it, because it disallows my program from ever being swapped out -- it continually consu

Re: [pygtk] Hooking into Gtk iterations

1999-02-25 Thread Aaron Optimizer Digulla
Quoting Hrvoje Niksic <[EMAIL PROTECTED]>: > > As for doing a python no op, I have no idea how python triggers the > > calling of signal handlers > The signal handlers are queued up somewhere; Python will empty the > queue as soon as it gets the chance -- I'm certain of that. A no-op > would be

Re: [pygtk] Hooking into Gtk iterations

1999-02-25 Thread Hrvoje Niksic
James Henstridge <[EMAIL PROTECTED]> writes: > As for doing a python no op, I have no idea how python triggers the > calling of signal handlers The signal handlers are queued up somewhere; Python will empty the queue as soon as it gets the chance -- I'm certain of that. A no-op would be quite s

Re: [pygtk] Hooking into Gtk iterations

1999-02-25 Thread James Henstridge
the quit_flag and call_quit_handlers() were pseudo code (I should probably have made that more clear). The quit_flag is actually a static variable in gtkmain.c and the call_quit_handlers() is actually part of gtk_main() (well it was last time I checked -- it probably is part of glib now). As for

Re: [pygtk] Hooking into Gtk iterations

1999-02-25 Thread Hrvoje Niksic
James Henstridge <[EMAIL PROTECTED]> writes: > I suppose you could use an idle function. It would get called for > each iteration of the main loop, and should allow the signal handler > to be called. I tried that now, but idle functions suck for that purpose. They are called all the time when

Re: [pygtk] I can't make work set_state

1999-02-25 Thread Richard Fish
[EMAIL PROTECTED] wrote: > Now my problem with set_state: > I can't set the state of a radio button... > Below is an example where I change the state of the 8 bits radiobutton to > 1 but when you run this script it's the 16 bits radiobutton that appears > pusshed. > What I'm I doing wrong ??? Try

Re: [pygtk] I can't make work set_state

1999-02-25 Thread Chi-Deok Hwang
> self.bit_num_button16 = GtkRadioButton(None, "16 bits") > bit_num_box.pack_start(self.bit_num_button16) > self.bit_num_button8 = GtkRadioButton(self.bit_num_button16, "8 bits") > bit_num_box.pack_start(self.bit_num_button8) > self.bit_num_button8.set_state(TRUE) #HE