Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2000:
[Freeciv-Dev] Re: Diplomat menu popup on goto
Home

[Freeciv-Dev] Re: Diplomat menu popup on goto

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Diplomat menu popup on goto
From: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Date: Mon, 03 Apr 2000 04:32:22 -0500

At 2000/03/25 19:03 , Thue Janus Kristensen wrote:
>I just accidentally thought about it and then it struck me that it would be a
>great feature if it didn't pop up the dialog when I entered one of my own
>cities!

Attached is a patch which does the following:

- Moves process_caravan_arrival() from gui-*/dialogs.c to control.c -- the
code was almost exactly the same in all three GUIs.

- Adds process_diplomat_arrival() to control.c.  Changed the new client
side handle_diplomat_action() to call process_diplomat_arrival(), rather
than popup_diplomat_dialog() (as David explained in his email, popup on
goto must respect the modality of the Diplomat action -vs- city dialog).

- Adds caravan_dialog_is_open() and diplomat_dialog_is_open() to
dialogs_g.h and gui-*/dialogs.c to support the process_*_arrival() routines.

- Added lots of stuff to implement the queued Diplomat dialog to
gui-xaw/dialogs.c and gui-gtk/dialogs.c.  I added a stub
caravan_dialog_is_open() to the MUI client, but it needs to be implemented.

- Removed diplomat-specific code from request_move_unit_direction().  Now
handled via server notification (much like caravans).

- Changed a printf() to freelog() in the new code.  Shouldn't use printf()s.

- I didn't like throwing an unrelated value into "enum diplomat_actions",
so I moved it to a new "enum diplomat_client_actions".

- The previous patch didn't work in the special case where the diplomat
that was gotoing ran out of movement on a square adjacent to the city to
which he was moving.  Early in the next turn, it was noticed that he was
moving into a city, and the new action packet was sent to the client
*before* the diplomat's unit information was being transmitted.  (This may
also have caused the unit information to be incorrect whenever a gotoing
diplomat moved to a city, but I didn't test it.)  I solved this by simply
sending the diplomat's unit information immediately prior to sending the
new action packet.

I didn't test this exhaustively; it could still easily contain a few bugs.

Attachment: diplomat_goto_popup-2.diff.gz
Description: Binary data

jjm

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