Hi, > Gesendet: Montag, 03. August 2015 um 12:26 Uhr > Von: "Michael T. Pope" <mp...@computer.org> > An: "FreeCol Developers" <freecol-developers@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 > win...@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 ------------------------------------------------------------------------------ _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
