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@xxxxxxxxxxxxxxxxx>
Date: Thu, 27 Feb 2003 01:57:36 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Thu, Feb 27, 2003 at 01:39:17AM -0800, Jason Short wrote:
> Raimar Falke wrote:
> > On Wed, Feb 26, 2003 at 04:35:16AM -0800, Jason Short wrote:
> > 
> >>Raimar Falke wrote:
> 
> >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.

> The problem is it is not simple.  I've already given a specific example 
> of how it can fail in a difficult-to-trace way.  The general problem is 
> that this code should be kept localized, and should not depend on global 
> changes done somewhere far away.

IMHO finish_gui_callback is a quite localized place.

> Note, this "general problem" was a problem for the original architecture 
> as well.  When you call center_tile_mapcanvas you have to know to call 
> flush_dirty afterwards.  Fortunately, we can do better.
> 
> >>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.
> 
> Why would a change to gui-gtk ever break gui-win32?

If we use the re-entrant feature of gtk_main there must a reason. In
most cases the same reason applied to the other clients.

> >>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.
> 
> Patch attached.

> I've added this form of support for GTK, XAW, and Win32, while removing 
> the flush_dirty calls from these GUIs.

The semantics in the gtk case are described well based on
gtk_idle_add. However in the xaw and win32 case is there something in
the docu which says that the callbacks are put at the end of the event
queue? Is there something which says that these callbacks aren't
immediately if the timeout if 0? If this isn't the case we can remove
the callbacks and call it directly.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Of course, someone who knows more about this will correct me if I'm
  wrong, and someone who knows less will correct me if I'm right."
    -- David Palmer (palmer@xxxxxxxxxxxxxxxxxx)




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