[Resending to the list, where it should have gone first time, sorry wintertime]
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. > 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
pgp5SBdmA2ce4.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
