On Sun, 2016-01-31 at 11:41 +0000, Chris Vine wrote: > On Sun, 31 Jan 2016 10:45:18 +0100 > Stefan Salewski <mail@xxxxxxxxxxxx> wrote: > > https://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-main-iteration > > > > I have some problems to understand and correctly use this function. > > > > Last week I wrote a toy chess game from scratch in Nim language, just > > to get some more experience with Nim and to have one more test and > > example for my Nim GTK3 bindings. For the plain GUI display with chess > > pieces drawn with unicode fonts I followed well known C examples code. > > > > My chess engine replies synchronously within less than one second -- > > well that may be not really good design, but for now that is OK for > > me. > > > > When human made a move, I wanted to update display at once, before > > reply is called. I found out fast that calling gtk-main-iteration is > > necessary. But it seems to be necessary to call that at least twice! I > > do not really understand why, or when that is really necessary, how I > > can call it in a loop. > > You can call gtk_main_iteration() in a while loop with > gtk_events_pending() as the condition. Thanks, I guess that may work. > Doing so is sometimes necessary > if you are trying to plumb two different main loop implementations > together, but otherwise it is often an indication of a defective > design. Why aren't you just letting the glib main loop do its thing, > following a call to g_main_run(), gtk_main() or g_application_run()? > Currently I can not really understand your hints with "g_main_run(), gtk_main() or g_application_run()". In the past I had always applications with spent nearly no time in a callback, like my Ruby schematics editor. Current Nim code follows the C conventions, it may look a bit different, but basically it is plain C. gtk_init() is called, then widgets are created and callback functions are connected to signals. At the end gtk_main() is called. From this point on all activity happens in the callbacks. Maybe your intent was to rewrite it to this shape: proc main_proc = gtk3.init_with_argv() var window = window_new() var darea = drawing_area_new() darea.add_events(EventMask.BUTTON_PRESS_MASK.gint) window.add(darea) discard g_signal_connect(darea, "draw", g_Callback(onDrawEvent), nil) discard g_signal_connect(darea, "button-press-event", g_Callback(onButtonPressEvent), nil) discard g_signal_connect(window, "destroy", g_Callback(main_quit), nil) window.position = WindowPosition.Center window.set_default_size(800, 800) window.title = "Plain toy chess game, GTK3 GUI with Unicode chess pieces, coded from scratch in Nim" window.show_all gtk3.main() main_proc() But I think that is basically the same executable code. And it behaves the same: When I remove both calls to gtk_main_iteration in the onButtonPressEvent() callback, then redraw occurs delayed about one second when call to reply() returns. Do you know an not too complicated example where code in a callback is called which may block for about one second? In the long term I may switch to a asyncroneously design, but currently I have no idea how to do that best. Have you a hint for that approach? _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
