Re: gtk-main-iteration -- use and understanding
- Date: Sun, 31 Jan 2016 14:10:42 +0100
- From: Stefan Salewski <mail@xxxxxxxxxxxx>
- Subject: Re: gtk-main-iteration -- use and understanding
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 =
var window = window_new()
var darea = drawing_area_new()
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.title = "Plain toy chess game, GTK3 GUI with Unicode chess pieces, coded from scratch in Nim"
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
gtk-list mailing list