Re: dialog enhancements

[Owen Taylor <otaylor redhat com>]

Fritz Jetzek <fritz.jetzek@i-dmedia.com> writes:

> Owen Taylor wrote:
> > 
> > gtk_main(), like any other GTK+ function when threading must be called
> > inside the GTK+ lock. Unlike most other functions, gtk_main()
> > releases the lock while waiting so other threads can get accses
> > 
> > So, as long as you are calling it from the main thread, and within
> > the main loop, a recursive gtk_main() will work with no problems
> > with threads.
> > 
> > (One thing that is NOT handled well now is doing the equivalent of a
> > recursive main from a different thread, since the GMain functions can
> > only be called from the main loop thread. To do this now, you
> > need to use a semaphore or some such mechanism in the secondary thread.
> > This would be nice address for GTK+-1.4.)
> > 
> > > So when rethinking the GtkDialog API one should possibly rethink whether
> > > the call to gtk_main is really necessary. Apart from not being able to
> > > use the preset dialog routines it also took me ages to actually find
> > > that bug...
> > 
> > I don't actually follow the problem. The only one I see is that
> > gnome_dialog_run() is only going to work in the main thread.
> > 
> > Regards,
> >                                         Owen
> 
> Consider a GTK application that allows multiple concurrent calls to ssh
> to connect to remote machines. Of course at some point the remote ssh
> server will ask for a password, and the local GTK application should
> respond to that. This introduces the possibility of having multiple
> gnome_dialogs at the same time (e.g. to let the user type in the
> password). This of course requires multithreading, and furthermore,
> calls to gtk_main() from other than the main thread.

No, it requires (or makes desirable) the ability to wait for modal
dialogs in something other than the main thread. There are ways
of accomplishing that now, but it could be more convenient.

[ I don't actually see how what Tim was proposing solves the problem
  one bit. It's just equivalent to a recursive gtk_main() ]
 
> This may sound as a very specific solution but IMHO it is not. In my
> case, it is just an application that allows to run file integrity
> checkers on multiple hosts; but the mechanism is the same for any app
> that calls several shell commands concurrently and has to react on their
> output in some way or the other.
> 
> Now how about just hacking gnome/gtk_dialog_run to allow the user
> passing the blocking function to it?

I think that would be an inconvenient interface that doesn't add much
extra flexibility. GtkDialog should be useable without calling
gtk_dialog_run(), so the potential for blocking in your own way is
always there.

But for GLib-1.4, I should probably change g_main_run(loop) so when
not run in the main thread, it simply waits for g_main_quit(loop).

(Having the ability to have multiple main loops running in different
threads is something that is desired to do for GLib-1.4, so there
will be changes in that area already.)

Regards,
                                        Owen