Robert Pearce wrote:
That function is fine if you want to execute the dialog as a "modal" dialog,
i.e. the other windows block until it's been acknowledged. If you want the dialog
non-modal (i.e. works in parallel with other windows) you should use a different approach.
I want the message box to be modal, that's fine.
You appear to be showing the dialog whenever the GTK loop is idle. This seems a
very unlikely requirement for a modal dialog.
Sorry that you misunderstood my code... in Python, /None/ is returned by
default which means the idle function only runs once (like returning
FALSE in a GTK written in C). So it's /not/ a problem with re-running
the dialog all the time.
The dialog does not disappear, the buttons stays pressed and the complete
application is stuck. Same with timeout_add, of course.
To be more accurate: As soon as I press the OK button, the button stays
pressed. I'm 99% sure that its signal handler deadlocks because GTK
signal handlers call gtk.gdk.threads_enter theirselves (according to the
FAQ). I think that this OK button signal handler and something in the
top-level window's main loop both try to call gtk.gdk.threads_enter
which then leads to the deadlock. Doing my workaround (= threads_enter
surrounding the dialog run) will let any other threads_enter calls from
the top-level window's main loop block.
Does that make any sense?!
_______________________________________________
gtk-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-list
