On Sun, 12 Dec 2021 09:01:05 +0000
Stian Grenborgen <stian...@student.matnat.uio.no> wrote:
> The point is that we might need to write more automated tests. Writing GUI 
> tests is quite difficult right now since we lack the supporting code.

Quite so.  The test suite has prevented many game logic regressions, and I
have long wished it covered more GUI aspects.

> It would have been great having GUI tests that verify that the number of 
> calls on certain methods (like displayMap) are kept below a threshold.

:-).  displayMap is a beast.

> We could even automatically check for changes in rendering of both maps
> and panels by automatically retrieving an image of the current behavior
> and compare it to a previously retrieved image.

That is partly achievable without GUI twiddling as the intermediate
routines (mostly in ImageLibrary) are suitable for simple unit tests.
Lots of picky work though.  You will notice me not rushing to volunteer.

> The modal JInternalFrame was created when we had synchronous communication 
> between the server and client, with only one game event handled at the time. 
> This avoided having several modal dialogs at the same time (which produces 
> the game hang). The point of making the dialog modal was to prevent changes 
> to the game state before the question was answered.

Which continues to make sense in some places.  By the time I joined
FreeCol I think it had stopped being fully synchronous, possibly to
support multiplayer.  There are some nasty cases with multiplayer, the
worst of which is when two human players are engaged in a diplomatic
trade, because that can go back and forth multiple times until resolved.
(Worse, for a while we had bugs where an AFK human could just hang the
game due to not responding to certain messages (now fixed by use of
TimedSession))  Consider two players concluding a diplomatic trade,
but where one player cunningly removes one of the traded items just before
accepting the trade. If I have done things correctly, that should not
actually work, but that is an example where a modal dialog might be useful
to discourage shenanigans.  (Just checked, NegotiationDialog is modal)

> The problem now is that the server can asynchronously update the client while 
> we are waiting for a response. The question then is why we are still using 
> modal dialogs?

There was some discussion about this a while back.  My view (which
prevailed because I then and went and did the work:-) was that we should
minimize the use of modal dialogs except where needed to maintain Col1
compatibility (IIRC the "goods party" accept/reject is modal).  FTR I
generally dislike modal dialogs --- FreeCol often throws up decisions
where I might want to pull up a colony panel to help work out what to do,
and possibly even fix some issue there, before returning to the decision
dialog.  That said, I am sure there are modal dialogs out there that I
missed... 
 
> What about changing code like this:
> 
> if (gui.confirm("quitDialog.areYouSure.text", "ok", "cancel")) {
>     Player player = getMyPlayer();
>     if (player == null) { // If no player, must be already logged out
>         quit();
>     } else {
>         getConnectController().requestLogout(LogoutReason.QUIT);
>         quit();
>     }
> }
> 
> ...into using a callback:
> 
> gui.confirm("quitDialog.areYouSure.text", "ok", "cancel", () -> {
>     Player player = getMyPlayer();
>     if (player == null) { // If no player, must be already logged out
>         quit();
>     } else {
>         getConnectController().requestLogout(LogoutReason.QUIT);
>         quit();
>     }
> });

...like that one.  I think I had a policy that game-ending decisions could
stay modal, and just minimized the in-game ones.  Its been a while since
this work was done, probably burned out a bit doing it.  A fair comment
when this was discussed was that the modal code is simpler.

Summary: There are still modal dialogs in FreeCol despite some effort
to the contrary.  We can certainly revisit any remaining ones.

Cheers,
Mike Pope

Attachment: pgpqgytwlPn5D.pgp
Description: OpenPGP digital signature

_______________________________________________
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers

Reply via email to