[Freecol-developers] 0.11.4

[Michael T. Pope]

The FreeCol 0.11.4 commit has been made (git.ecbc3b7) but the release
upload is stuck at sourceforge. Nevertheless feel free to push on
with anything we have postponed until after release[1]. Hopefully the
download directory will be live by this time tommorow, at which point
I will upload the website changes, post the release announcements, and
update the trackers.

Thanks to everyone who has contributed to the best release of FreeCol
ever[2], particularly to the new members of the development team.

Looking ahead, my personal rough plans are:

- I have several minor patches (often annotated TODO-post-0.11.4)
backed up due to the string freeze which I want to revise and clear
out.

- After that I will look at other things that were stalled by the
release, such as Fenyo's contributions and the client options
handling improvements discussed here.

- I have a bunch of work in the general category of enhanced trade
routes, which I have been play testing. It is looking good, but needs
better messages and documentation.

- I have a short list of "Stupid AI tricks" that I have seen in recent
play testing. It is about time for some more AI enhancements.

- However the main game has to be the PF list, probably starting with:
#36, #23, #24, #26, #59.

More general thoughts for the next release:

- We should move to Java 8. Opinions on timing solicited.

- There is some magic in ReportTurnPanel.insertMessage that makes some
items on the turn report clickable. I would really like to make more
things clickable, and expand this to other panels. And while we are
at it, implement the IR that calls for text to be cut-and-pasteable.

- This time, fixing America_large should be a release-blocker.

- Keep hammering on the bug list, we should be able to get it below 40
unless we get a lot of new needs-info reports.

- Even better would be to get the PFs below 30. There are 43 open
ATM, of which I think we can at least improve 23 without depending
on more WWC1D progress. Indeed, if we reach a point where the open
PFs are all low priority (e.g. PF#2) or WWC1D quantitative issues
(PF#34), it will be time for v1.0 IMHO.

Cheers,
Mike Pope

[1] Especially anything that would benefit from independent testing,
the earlier in a cycle such work is committed the better.

[2] OK, I always think that.

[w***@genial.ms]

Hi,

> The FreeCol 0.11.4 commit has been made (git.ecbc3b7) but the release
> upload is stuck at sourceforge. Nevertheless feel free to push on
> with anything we have postponed until after release[1]. Hopefully the
> download directory will be live by this time tommorow, at which point
> I will upload the website changes, post the release announcements, and
> update the trackers.

I saw we have no git tags. I think its customary to do a
git tag -a v0.11.4
(some might instead do a tag -s, if they feel its useful).
You may want to checkout the commit, tag and push, to make it easier
for users or packagers to checkout the release.

SF uploads seem to be not repaired still, I guess it takes some more days.
I could see some of your uploads named git-date, but downloading failed.
You saw they want to sell off SF and Slashdot soon? Not the best time
for such an announcement.

> Thanks to everyone who has contributed to the best release of FreeCol
> ever[2], particularly to the new members of the development team.

:)

> Looking ahead, my personal rough plans are:
> ...
> - However the main game has to be the PF list, probably starting with:
> #36, #23, #24, #26, #59.

- Most of the PF are out of my reach atm, as they are marked Server /
AI / WWC1D. I guess we don't have descriptions of the server and
network protocol.
Exceptions where I might reach some progress are #44, #60 and,
oh the irony, the one I argued against doing, #2. Not sure if I do.
- I'd like to move some bits and pieces of code between controllers
and gui classes, to get a clearer separation of responsibilities.
- I'd like to clean up GUI some more to only contain the minimum
external API and hide everything else.
- I might clean up the code for image resizing some more to make it
easier for mods to replace images, by allowing differently sized ones.
- I don't particularly like to, but some gui subpanels need to get
transparent background to avoid weird looking pattern changes when
they are contained inside another panel, which already provides one.
- I'd like to intergrate some more unused or higher res art files
from the SVN, but can not extract the psd files.

> More general thoughts for the next release:
>
> - We should move to Java 8. Opinions on timing solicited.
>

Windows users mostly would get Java from Oracle website and only 8
is shown there. Not sure if you can even download 7 anymore without
paying a few hundred bucks. People who forgot to upgrade we can tell.
For Linux, I guess its same as when we talked about still needing
0.10.7 compatibility. When 8 is in debian stable and derivatives,
we might update.
Mac, I dont know what they can download.

> - Keep hammering on the bug list, we should be able to get it below 40
> unless we get a lot of new needs-info reports.

Sadly, most easily fixable bugs are gone. There is missing artwork,
Java problems, some vague problems with no clear solution or missing
information.

> - Even better would be to get the PFs below 30. There are 43 open
> ATM, of which I think we can at least improve 23 without depending
> on more WWC1D progress. Indeed, if we reach a point where the open
> PFs are all low priority (e.g. PF#2) or WWC1D quantitative issues
> (PF#34), it will be time for v1.0 IMHO.
To me it feels like most are blocked on WWC1D, even some without the tag.


Greetings,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

On Wed, 29 Jul 2015 18:23:02 +0200
***@genial.ms wrote:
> I saw we have no git tags. I think its customary to do a
> git tag -a v0.11.4

I no longer bother with tags. They seem like an old habit from when
vcs branching was expensive. I just keep a branch around:

git checkout -b 0.11.4 ; git reset --hard ecbc3b7

which only burdens my local repo copy.

> SF uploads seem to be not repaired still,

This is the most annoying part of the outage. The git-date uploads were
working on the weekend. But now they are not. The latest statement is:

File upload service data has been reconstructed and is pending final
copying, ETA for service restoration is end of day 7/31.

So, perhaps some time on the weekend. Small consolation prize for the
delay; the final packages will include a backport of the fix for BR#2878.

> You saw they want to sell off SF and Slashdot soon? Not the best time
> for such an announcement.

I see no evidence their corporate parent has a clue. Might be for the
best for all concerned. I still like /.

>[future plans]
> - Most of the PF are out of my reach atm, as they are marked Server /
> AI / WWC1D. I guess we don't have descriptions of the server and
> network protocol.

The AI is still tough to work with. The protocol is easy to watch if you
are curious (just enable COMMS debug mode). Many of the WWC1D bugs are
hard to get *Right*, but we do not have to get them right in one step, it
is still worthwhile if they get better. For example, I have no real idea
of how the sailing-to-Europe-post-Independence functionality should work,
but I am prepared to work up a trial implementation and see how it stands
up.

> Exceptions where I might reach some progress are #44, #60 and,
> oh the irony, the one I argued against doing, #2. Not sure if I do.

I hope you dont! #2 surely should be lowest priority. #60 should be
straightforward.

> - I'd like to move some bits and pieces of code between controllers
> and gui classes, to get a clearer separation of responsibilities.
> - I'd like to clean up GUI some more to only contain the minimum
> external API and hide everything else.
> - I might clean up the code for image resizing some more to make it
> easier for mods to replace images, by allowing differently sized ones.

These are all good things to have done, which will prevent future
problems, and you are the best placed to work on them.

>>[Java 8]
> Windows users mostly would get Java from Oracle website and only 8
> is shown there. Not sure if you can even download 7 anymore without
> paying a few hundred bucks. People who forgot to upgrade we can tell.
> For Linux, I guess its same as when we talked about still needing
> 0.10.7 compatibility. When 8 is in debian stable and derivatives,
> we might update.

I do not think we have to worry about slow linux distros. If debian
does not update FreeCol, then they do not care what Java we use, if they
do update, they will need to at least provide the Java8 runtime or it just
will not work. Its their choice. The 0.10.7-compatibility question is
different, because when we break the save game format, we cause problems
for users, who are often far less able than a distro-packager.

> Sadly, most easily fixable bugs are gone. There is missing artwork,
> Java problems, some vague problems with no clear solution or missing
> information.

I eventually close the need-info ones if they stay open too long without
response. What would be *really* good is to make some progress with the
"window goes behind the map" class of bug. Alas, I fear they are
intractable.

Cheers,
Mike Pope

[Michael T. Pope]

On Wed, 29 Jul 2015 18:23:02 +0200
***@genial.ms wrote:
> - I'd like to move some bits and pieces of code between controllers
> and gui classes, to get a clearer separation of responsibilities.

With respect to the setActiveUnit untangling, I looked at git.b8c21dc
where the colony popup went away. I think a case was missed, so I put it back,
and dropped as many setSelectedTile calls as possible (git.8394732).
Related to this I have just put in the fix for the second race in BR#2867,
which simplifies the InfoPanel in MOVE_UNITS_MODE (git.1728101). This has
probably caused more cases of a blank InfoPanel, which will need fixing as
they are understood. The intention now is that IGC should keep an active
unit displayed at all times, until it runs out of them or the user explicitly
goes into terrain mode (formerly we would clear the active unit in some
cases such as when abandoning a colony, however this was arbitrary).

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> With respect to the setActiveUnit untangling, I looked at git.b8c21dc
> where the colony popup went away. I think a case was missed, so I put it back,
> and dropped as many setSelectedTile calls as possible (git.8394732).

I might have overlooked it, as I did not think code was relying on setActiveUnit
internally calling setSelectedTile which was opening the panel.

> Related to this I have just put in the fix for the second race in BR#2867,
> which simplifies the InfoPanel in MOVE_UNITS_MODE (git.1728101). This has
> probably caused more cases of a blank InfoPanel, which will need fixing as
> they are understood.

When I saw the diff I suddenly had the idea what the reason for BR#2806 is.
It must be the InfoPanel not knowing about the next active unit.
I pushed a tentative fix, but I could not do checking for how it influences
BR#2867. Could you do that?
We might also recheck if the active unit in MapViewer also needs an update
and if thats the case it might be better to update the InfoPanel by doing some
call from somewhere else instead of letting it just grab the next unit.

> The intention now is that IGC should keep an active
> unit displayed at all times, until it runs out of them or the user explicitly
> goes into terrain mode (formerly we would clear the active unit in some
> cases such as when abandoning a colony, however this was arbitrary).

I'll try to remember this.


Regards,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

On Fri, 31 Jul 2015 19:22:22 +0200
***@genial.ms wrote:
> > Related to this I have just put in the fix for the second race in BR#2867,
> > which simplifies the InfoPanel in MOVE_UNITS_MODE (git.1728101). This has
> > probably caused more cases of a blank InfoPanel, which will need fixing as
> > they are understood.
>
> When I saw the diff I suddenly had the idea what the reason for BR#2806 is.
> It must be the InfoPanel not knowing about the next active unit.
> I pushed a tentative fix, but I could not do checking for how it influences
> BR#2867. Could you do that?

I think you have just reinstalled the possibly racy code with the call
to hasNextActiveUnit:-P.

BR#2806 is due to the InfoPanel not knowing about the *current active
unit*. What needs to happen is to find where it fails to get updated. It
must be a (rare) action, probably in IGC where we fail to call
updateActiveUnit. I have been on the look out for it in my play testing,
but do not recall seeing it lately. It may even be fixed.

However, what *is* broken is the terrain mode. AFAICT, "Toggle View Mode"
is not working.

BTW, do not be alarmed if there are heaps of semi-pointless messages
coming out of the IR tracker. There are a lot of requests there with no
assigned "Milestone" (not to mention quite a few that are fixed or
implemented, and some that need to die). I am going through and fixing
this so that they show up as "Accepted", usually by making a trivial
change to priority.

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Samstag, 01. August 2015 um 12:57 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: "FreeCol Developers" <freecol-***@lists.sourceforge.net>
> Betreff: Re: [Freecol-developers] 0.11.4
>
> On Fri, 31 Jul 2015 19:22:22 +0200
> ***@genial.ms wrote:
> > When I saw the diff I suddenly had the idea what the reason for BR#2806 is.
> > It must be the InfoPanel not knowing about the next active unit.
> > I pushed a tentative fix, but I could not do checking for how it influences
> > BR#2867. Could you do that?
>
> I think you have just reinstalled the possibly racy code with the call
> to hasNextActiveUnit:-P.
>

Sorry :P
Btw., I was not happy how your fix did hide the appearance of BR#2806,
as it would just wrongly display the end of turn message instead of the
empty state, when there might still be activatable units left.
We need to find a better solution.
What we are currently having is manual updates and copying around of that
information to multiple classes (some model class, MapViewer, InfoPanel, ...),
which can easily get out of sync, if a single copy is not made somewhere,
and adds much tedious busywork when coding.
Generally, I would prefer there be a central place containing the definitive
answer to which unit is activated at that time. That place should be polled
by all other methods in need of the information, at the time of immediate need.
I'm not sure if its better keep it in a model class or, as this need not be
saved, some new gui-state class, but both is better than manual copy/update
at state change.

> However, what *is* broken is the terrain mode. AFAICT, "Toggle View Mode"
> is not working.

For me it was always working when I used it.
We should just cut down on automatically toggling that state and just keep
it as set by the user.

> BTW, do not be alarmed if there are heaps of semi-pointless messages
> coming out of the IR tracker. There are a lot of requests there with no
> assigned "Milestone" (not to mention quite a few that are fixed or
> implemented, and some that need to die). I am going through and fixing
> this so that they show up as "Accepted", usually by making a trivial
> change to priority.

I'm actually happy you took the time now to reprioritise these, I sometimes
tried to update a few but had not enough information to change most and
did not want to spam all of them asking if they needed an update.
But I read in the developer docs the accepted setting should be reserved
only for items where the dev team is committing to implement them
_for the next release_. I actually find that easier, too, as then there
is a smaller amount of tracker items to pay immediate attention to,
without 100 other items also being accepted, although its uncertain when/if
any work will be done on them.

Is it worth looking at the Ideas for FreeCol2 tracker, if something with
an earlier usefulness is buried there?

Btw., is the stuff in the restructuring tracker relevant anymore?
What is actually the purpose of that tracker, announcing refactorings?
Do we need it at all?

Do we need the support tracker? Caleb and me closed the few ancient items,
which had been there, so its empty now. People mostly just write a BR or,
if uncertain, ask in the forum.

Wouldn't it be better to have a separate tracker for Missing Artwork and
other things related to that? The ancient opening mail in the graphics
list promised such a tracker and people with artistic skills would
probably not see such requests when they are buried inbetween a hundred
bug reports.

In an earlier mail you said you feel tags are unnecessary, but now I
actually can not see easily which commit, if any, is containing exactly
the same code as in the downloadable files, as I remember you wanted
to backport some bugfix (but noone will remember that later).
Branches are nice for development, but tags are useful for marking a
fixed release, such that people can clone, then git tag --list, then
choose a tag to easily type it in the checkout command, to get a
release commit.

Oh and I tried out the installer from the download section. First I
was irritated I did not see the option to create a desktop shortcut,
but on second try it did show up, so it might have been just a too fast
click being registered twice.
I can say it worked as good as the ones I compiled when trying it out
earlier.


Greetings,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

[Resending to the list, where it should have gone first time, sorry
wintertime]

On Sat, 1 Aug 2015 14:56:52 +0200
***@genial.ms wrote:
> Btw., I was not happy how your fix did hide the appearance of BR#2806,
> as it would just wrongly display the end of turn message instead of the
> empty state, when there might still be activatable units left.
> We need to find a better solution.

Quite so. Trust me though, I have been chasing BR#2806 for quite some
time now. The InfoPanel call was making it *harder* to trigger by
papering over the underlying problem. The fact that it was implicated in
a race condition was enough to convince me that call had to go.

> What we are currently having is manual updates and copying around of that
> information to multiple classes (some model class, MapViewer, InfoPanel, ...),
> which can easily get out of sync, if a single copy is not made somewhere,
> and adds much tedious busywork when coding.
> Generally, I would prefer there be a central place containing the definitive
> answer to which unit is activated at that time. That place should be polled
> by all other methods in need of the information, at the time of immediate need.
> I'm not sure if its better keep it in a model class or, as this need not be
> saved, some new gui-state class, but both is better than manual copy/update
> at state change.

Also quite so. However, I have also stated my solution: that the client
IGC *is* the centralized place that has the definitive answer to which
unit is activated. It even has a routine to do this, called
updateActiveUnit, which calls gui.setActiveUnit as it should.
It is regrettable that the client IGC is complex, and still has a few
special cases, but there are significantly less than there used to be.
As I said, work has been ongoing here for a while.

Let me restate the principle:

> The intention now is that IGC should keep an active
> unit displayed at all times, until it runs out of them or the user explicitly
> goes into terrain mode...

IGC *should* be calling gui.setActiveUnit, which should filter down into
updating the InfoPanel. The InfoPanel should be a passive client, doing
what it is told, and *not* call back up to query for the active unit. ISTR
you like things to be untangled:-)?

If we untangle this, hopefully then the circumstances in which we see
empty InfoPanels when there *is* a useful active unit available will
become more apparent, and we can finally nail BR#2806.

> > However, what *is* broken is the terrain mode. AFAICT, "Toggle View Mode"
> > is not working.
>
> For me it was always working when I used it.
> We should just cut down on automatically toggling that state and just keep
> it as set by the user.

Agreed. So is it working for you still or is it just me?

> I'm actually happy you took the time now to reprioritise these, I sometimes
> tried to update a few but had not enough information to change most and
> did not want to spam all of them asking if they needed an update.

Now is a good time for the spamming:-S. A clean out was certainly needed,
although it was partly driven by feeling ill and refraining from serious
development in favour of something more mechanical.

> But I read in the developer docs the accepted setting should be reserved
> only for items where the dev team is committing to implement them
> _for the next release_.

That may have been the intention once. It had failed well before I joined
the project. (Was that doco in developer.tex or somewhere on the
website? I should fix it) AFAICT "Accepted" had fallen back to mean "Good
idea, lets hope someone works on it one day".

> I actually find that easier, too, as then there
> is a smaller amount of tracker items to pay immediate attention to,
> without 100 other items also being accepted, although its uncertain when/if
> any work will be done on them.

Agreed that it could be hard to tell. Hence the clean out. The IRs are
now in much better shape, and if something is open you can assume it
remains unimplemented. Or I made a mistake.

> Is it worth looking at the Ideas for FreeCol2 tracker, if something with
> an earlier usefulness is buried there?

I have started on it. Its not going to get the same degree of scrutiny
though, as it by nature is a lot more speculative and prone to the multiple
issues on the same request problem.

> Btw., is the stuff in the restructuring tracker relevant anymore?
> What is actually the purpose of that tracker, announcing refactorings?
> Do we need it at all?

I think it can go, we are not using it.

> Do we need the support tracker? Caleb and me closed the few ancient items,
> which had been there, so its empty now. People mostly just write a BR or,
> if uncertain, ask in the forum.

Likewise. Anyone objecting to "restructuring" and "support" being
removed soon should be speak up now.

> Wouldn't it be better to have a separate tracker for Missing Artwork and
> other things related to that?

Actually I think we should improve the tags on the BRs. I added "Media
Needed" as a "milestone" for the IRs and intend to do that for the BRs and
PFs when I get back to them. Do you have other suggestions so that we can
make the more tractable BRs more obvious?

> In an earlier mail you said you feel tags are unnecessary, but now I
> actually can not see easily which commit, if any, is containing exactly
> the same code as in the downloadable files, as I remember you wanted
> to backport some bugfix (but noone will remember that later).

0.11.4 is an oddity in that what was released is <commit-A> +
cherry pick <commit-B>. I intended committing a branch for the final
release binary. However, BR#2885 is highly exasperating, and if we do a
quick 0.11.5 I am not convinced its worth the bother any more.

> Branches are nice for development, but tags are useful for marking a
> fixed release, such that people can clone, then git tag --list, then
> choose a tag to easily type it in the checkout command, to get a
> release commit.

Your call. If you want tags, you have git commit rights:-). I am
just indifferent to that use case.

> Oh and I tried out the installer from the download section. First I
> was irritated I did not see the option to create a desktop shortcut,
> but on second try it did show up, so it might have been just a too fast
> click being registered twice.
> I can say it worked as good as the ones I compiled when trying it out
> earlier.

So can I take that as confirmation that the desktop shortcut has been
sighted as working, and thus can close IR#35?

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Montag, 03. August 2015 um 12:26 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: "FreeCol Developers" <freecol-***@lists.sourceforge.net>
> Betreff: Re: [Freecol-developers] 0.11.4
>
> [Resending to the list, where it should have gone first time, sorry
> wintertime]
>

NP. There had been so many mails for release preparation. I think I wanted
to answer it, but there had been another that was more urgent and then
I did not remember anymore.

> On Sat, 1 Aug 2015 14:56:52 +0200
> ***@genial.ms wrote:
> > Btw., I was not happy how your fix did hide the appearance of BR#2806,
> > as it would just wrongly display the end of turn message instead of the
> > empty state, when there might still be activatable units left.
> > We need to find a better solution.
>
> Quite so. Trust me though, I have been chasing BR#2806 for quite some
> time now. The InfoPanel call was making it *harder* to trigger by
> papering over the underlying problem. The fact that it was implicated in
> a race condition was enough to convince me that call had to go.
>

I have an idea now, I think MapControls.update is not called all the time
the viewmode, activated unit or looked at tile get changed, because MapViewer
internally routes some self-updates instead of calling out to GUI.
MapViewer is like the worst agglomeration of code there is, even though I
already cut out many pieces before.
I think moving these 3 mentioned states to a dedicated class is a good idea,
to detangle this net of calls and fix the bug.

> Also quite so. However, I have also stated my solution: that the client
> IGC *is* the centralized place that has the definitive answer to which
> unit is activated. It even has a routine to do this, called
> updateActiveUnit, which calls gui.setActiveUnit as it should.
> It is regrettable that the client IGC is complex, and still has a few
> special cases, but there are significantly less than there used to be.
> As I said, work has been ongoing here for a while.
>

Well IGC does not know, it asks (Swing)GUI (which routes that to MapViewer)
and also Player for infos and then figures out some changes, which it then
tells GUI again.

> Let me restate the principle:
>
> > The intention now is that IGC should keep an active
> > unit displayed at all times, until it runs out of them or the user explicitly
> > goes into terrain mode...
>
> IGC *should* be calling gui.setActiveUnit, which should filter down into
> updating the InfoPanel. The InfoPanel should be a passive client, doing
> what it is told, and *not* call back up to query for the active unit. ISTR
> you like things to be untangled:-)?
>

Yes, InfoPanel is mostly passive, but when its called to be informed of
an update it only gets partial information and then does back calling to
grab missing info. The back calling should be deleted.

> If we untangle this, hopefully then the circumstances in which we see
> empty InfoPanels when there *is* a useful active unit available will
> become more apparent, and we can finally nail BR#2806.
>

Yeah, I hope it can be detangled. The mess is consisting mostly a net of calls in
MapViewer and GUI/SwingGUI, also including some to IGC, MapControls and InfoPanel.

> > > However, what *is* broken is the terrain mode. AFAICT, "Toggle View Mode"
> > > is not working.
> >
> > For me it was always working when I used it.
> > We should just cut down on automatically toggling that state and just keep
> > it as set by the user.
>
> Agreed. So is it working for you still or is it just me?
>

Well, it needs checking anyway. As said above the view mode changing is probably
missing some calls to propagate updates.

> > Btw., is the stuff in the restructuring tracker relevant anymore?
> > What is actually the purpose of that tracker, announcing refactorings?
> > Do we need it at all?
>
> I think it can go, we are not using it.
>

Yeah, its not very useful.
In case you like some, maybe move the few items there to IR?

> > Wouldn't it be better to have a separate tracker for Missing Artwork and
> > other things related to that?
>
> Actually I think we should improve the tags on the BRs. I added "Media
> Needed" as a "milestone" for the IRs and intend to do that for the BRs and
> PFs when I get back to them. Do you have other suggestions so that we can
> make the more tractable BRs more obvious?

I saw your updates, but they are a bit inconsistent.
Each tracker had already different milestones, openness status and shown
colums, which is irritating. Now one of the art things is a milestone, the
other is open-need media.
Is it possible to make them all more alike the Bugs tracker?

> > Branches are nice for development, but tags are useful for marking a
> > fixed release, such that people can clone, then git tag --list, then
> > choose a tag to easily type it in the checkout command, to get a
> > release commit.
>
> Your call. If you want tags, you have git commit rights:-). I am
> just indifferent to that use case.
>

In theory I could, but was thinking I don't package the release, so I
was not really in position to find the right commit (which was never even
pushed) and tag it, and tried to persuade you. :p

> So can I take that as confirmation that the desktop shortcut has been
> sighted as working, and thus can close IR#35?

We dont need the icon from the IR and I guess its not better than the one
in git already. I think the IR was only about the zip package not having
it packaged inside (you may want to look inside, if you care).
The .exe installer always had it though, not sure about the .jar installer,
but it should be same.
So I guess you can close it?


Greetings,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

On Mon, 3 Aug 2015 21:28:15 +0200
***@genial.ms wrote:
>>[who knows what the current active unit is?]
> Well IGC does not know, it asks (Swing)GUI (which routes that to MapViewer)

I think this is overstating the case. IGC calls getActiveUnit in three
places:
1. saveGame, because the active unit has to go into the saved game
2. doExecuteGotoOrders, where it just saves the current unit so it can
restore it after doing all the automatic moves.

Neither of these cases are involve decision making. The only place
where the result of getActiveUnit is tested at all is:

3. updateActiveUnit, where it merely checks if the current active unit can
still move before looking for the next one.

AFAICT if we wanted to, IGC could just cache the last active unit it set
and eliminate these calls entirely, albeit for very little gain. It does
have to be in the GUI.

OTOH all the actual *decisions* about when the active unit needs
to change are made in the command-level routines in IGC, and end up in
calls to updateActiveUnit. I think my contention that IGC "has the
knowledge" is solid.

This is not to disagree with your point that MapViewer is a mess and is
probably confusing matters. Also, looking at IGC, I think the code can be
tightened further in a few places... patches underway.

> Yes, InfoPanel is mostly passive, but when its called to be informed of
> an update it only gets partial information and then does back calling to
> grab missing info. The back calling should be deleted.

Agreed.

> Well, it needs checking anyway. As said above the view mode changing is probably
> missing some calls to propagate updates.

I am pretty sure IGC is making the required calls, but I am looking for
omissions nonetheless. All I have found so far is places where it
probably makes too many. The suspicion is certainly that something is
getting lost in MapViewer.

>>[open-needs-media / Media_Needed]
> I saw your updates, but they are a bit inconsistent.
> Each tracker had already different milestones, openness status and shown
> colums, which is irritating. Now one of the art things is a milestone, the
> other is open-need media.
> Is it possible to make them all more alike the Bugs tracker?

That probably makes sense for the IRs. Low priority task. Next time I am
sick perhaps. FC2-tracker is a different case.

Cheers,
Mike Pope