Re: gtk-main-iteration -- use and understanding

[Stefan Salewski <mail ssalewski de>]

On Sun, 2016-01-31 at 11:41 +0000, Chris Vine wrote:
> On Sun, 31 Jan 2016 10:45:18 +0100
> Stefan Salewski <mail ssalewski de> 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?