Re: [Freecol-developers] TradeRouteInputPanel
On Sun, 12 Dec 2021 21:35:42 +0100 (CET) Stefan Fellner wrote: > I have been working on TradeRouteInputPanel the last week and I got it > running now. Will have a look soon. Out of time today. > I changed the layout so that you can now define which goods you want to load > and or unload at a particular stop. Also the Drag handling should work fine > now (you can drag the goodsTypes from the "AllGoodsPanel" to either the > import or export (load/unload) panel. Removing a goods is also possible with > right-clicking on the goodstype. The whole Drag/Drop system in FreeCol is rather weird. Java now has a preferred way to do drag/drop which we are only vaguely compatible with. > Plus, as you currently are discussing modality, I added a simple solution for > disabling the Actions (like Stian was suggesting), while defining an > FreeColPanel as "modal" (= quasi modal, actions are disabled while it > displays). Yep, there is functionality there in the ActionManager if you want it. My policy has been to minimize modality, so I rarely do. > Also I fixed at least one bug in the TradeRoute code, when a unit was > following a trade route which includes Europa as stop (the trade route was > interrupted, cause is a missing "else" in the InGameController). (The missing > else was causing the TradeRoute to be interrupted and the vessel stays in > Europe). Excellent! I think there is a BR that reports this. > BTW would be great to have a kind of review tool / process in place where we > could comment the changes (like when using pull requests / merge requests > with a tool, but can also be done with patches). Well, you can create a PR on the github mirror if you prefer that to just attaching a patch. > And I would really like it if we could maybe schedule a Skype, or Microsoft > Teams Meeting (or what else you prefer!) where all active and or interrested > devs would meet and discuss the next steps, progress, ...? > I know already that the current team is spread all across the globe :P > However this would be very helpful. We need to figure out a good timeslot > where it's not maybe 3 A.M. at anyone's time zone :P > If you are interested, tell me what time zones are to be considered? Not too keen on *more* meetings. Do you have a lot of questions? If there is one thing I insist on with FreeCol development, it is that we should be having fun. Meetings != fun. > I am in GMT +1 (Vienna). ACDT == GMT + 1030. Its a long time since I was in Vienna but we had a great time there, and Austria generally. Gday from Australia, that country you get confused with:-). > And because I am Austrian guy, my mother tongue is german, I could also walk > through the german translations, wording ... > Please tell me if this is a possible task! (probably not prio one). Sign up at translatewiki and see what you can see. I suspect the DE translation is pretty good though. But maybe it is too north-German? > And what next task is on the line? If nothing special / pressing comes to > your mind I will next try to go through my quick noted issue lists / and or > BR on the sourceforge BR queue. That would be my suggestion. There is a lot to choose from on the SF BR page! Cheers, Mike Pope pgpmeIfdwD_Bu.pgp Description: OpenPGP digital signature ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] [freecol:discussion] Re: Alternate methods of rendering the base terrain
On Sun, 12 Dec 2021 09:01:05 +
Stian Grenborgen 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
pgpqgytwlPn5D.pgp
Description: OpenPGP digital signature
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] [freecol:discussion] Re: Alternate methods of rendering the base terrain
> [Stian:] > The modal part of FreeColDialog will not prevent state altering operations > before the player gives an answer -- so why bother? I think my original getResponse-solution to FreeColDialog was a mistake. Sorry about that. If we really want modality it can better be achieved by disabling all actions through the ActionManager -- and placing all modal windows above an event-catching panel in JDesktopPane. Best wishes, Stian Grenborgen ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] [freecol:discussion] Re: Alternate methods of rendering the base terrain
>> [Stian:]
>> I have fixed several performance issues already. For example, we had a full
>> repaint of the
>> entire map every time the mouse moved 1px! We probably need better testing
>> in order to
>> avoid such problems in the future, as such mistakes are easy to make.
>
> [Michael T. Pope:]
> That was probably me earlier this/last year. [...]
No problem: Everyone who actually does something breaks stuff as well. Thanks
for working on FreeCol and making it better! :-D
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.
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. 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.
>> Adding such optimizations back in might be unnecessary, though, as ten year
>> old hardware
>> can render the entire map in HD several times per second. In addition, we
>> cannot add the
>> original code back in without also converting every JDialog back into a
>> JInternalFrame.
>
> The JDialog problem is my doing, and alas, I have to stand by it. I can
> remind you of the last time we discussed it below. TLDR: JDialog is a
> pain but an unfixable bug that hangs games inside our fake event loop
> is worse.
Thanks for the reminder :-)
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.
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?
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();
}
});
This simplifies getting the response. The modal part of FreeColDialog will not
prevent state altering operations before the player gives an answer -- so why
bother?
>> But then again, I think 250ms latency while moving the map is acceptable. My
>> guess is you want the latency to be lower than 100ms?
>
> 250ms for a big map change is fine. I was seeing really slow single unit
> moves (independent of animation) without any map changes. I just did a
> quick test of the current trunk and can not reproduce that ATM. When I
> get a bit more time together I will haul the old machine out of the shed
> and see if it is still there, but things are looking hopeful.
That's great news :-)
I was refering to Wintertime's: "Though, if you click on the map to move and
its not redrawn immediately cause of the many layers thats already too slow
IMO."
We need less than 100ms on full redraws in order to make map repositioning feel
instantaneous -- but I might have taken him a bit too literally.
Best wishes,
Stian Grenborgen
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
