Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#3424) New flush code
Home

[Freeciv-Dev] Re: (PR#3424) New flush code

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: bursig@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#3424) New flush code
From: "Raimar Falke" <rf13@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 26 Feb 2003 06:03:32 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Wed, Feb 26, 2003 at 04:35:16AM -0800, Jason Short wrote:
> Raimar Falke wrote:
> > On Wed, Feb 26, 2003 at 12:06:13AM -0800, Jason Short wrote:
> > 
> >>>I think you brought this up and I now think it is a good idea: calling
> >>>gui_callback_finished after each event. For this we have to break up
> >>>the main loop. This is possible for:
> >>> - xaw: http://www.xfree86.org/4.2.0/XtAppNextEvent.3.html
> >>> - gtk: 
> >>> http://developer.gnome.org/doc/API/gtk/gtk-general.html#GTK-MAIN-ITERATION
> >>> - gtk2: 
> >>> http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-main-iteration
> >>>
> >>>sdl, win32 and mui already have to loop broken up in the current
> >>>source code.
> 
> Because you are using the GUI in a way it was not designed to be used, 
> rewriting a function that is already written and works quite well 
> already.  It's just not a good idea in general to try to outwit the library.

From the XtAppNextEvent page above:

  There is nothing special about XtAppMainLoop; it is simply an loop that
  calls XtAppNextEvent and then XtDispatchEvent, until XtAppGetExitFlag()
  returns true.

From the GTK page above:

Example 2. Updating the GUI during a long computation

        /* computation going on */
...
        while (gtk_events_pending())
          gtk_main_iteration();
...
        /* computation continued */
 
I don't want to outwit the library. Both libraries provide a way to go a
layer deeper. With this extra control we can code a solution to the flush case
which is 100% correct and quite simple.

> One example is that gtk_main is re-entrant (although I doubt we use this 
> feature).  If it were ever used, it would completely break the flush code.

It would also break win32, mui and sdl. We would have to find an alternative
for these anyway.

> > I think it is the cleanest solution and the one
> > with the fewest possible errors.
> 
> Such a statement really needs disproving.
> 
> I submit that simply queuing a GUI event is many times "more clean" and 
> has many times "fewer errors".

Looks like we have no way to measure this.

> In the worst case this could be done 
> simply by adding a timeout with a timer of 0; gtk also supports this 
> type of operation via gtk_idle_add().

This is also possible.

        Raimar



[Prev in Thread] Current Thread [Next in Thread]