Re: [Freecol-developers] Release: DHYB
Hi, I mentioned that I got the manual printing to work on Windows recently, I think it was yesterday. The problem is tools for compiling .tex files were not installed. I got them from http://www.miktex.org/download and clicked there on other downloads and got the 64bit net installer. You need to run it twice, once for downloading and once for installation, but I only choose a nearby download mirror and did not have to change other options. I allowed it to download missing files later and on first time running ant it needed to download a few more things, but it worked flawlessly and produced the pdf. Greetings, wintertime Gesendet: Samstag, 25. Juli 2015 um 20:25 Uhr Von: "Caleb Williams" An: "FreeCol Developers" Betreff: Re: [Freecol-developers] Release: DHYB re: compiling on Windows I always had to run ant dist -Dprint.manual.is.up.to.date=true in order for the installer to compile into a .exe properly. That was some months ago, so I don't know what if anything has changed. Best, -- Caleb R. Williams -- ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
re: compiling on Windows I always had to run ant dist -Dprint.manual.is.up.to.date=true in order for the installer to compile into a .exe properly. That was some months ago, so I don't know what if anything has changed. Best, -- *Caleb R. Williams* -- ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
On Sat, 25 Jul 2015 09:18:38 +0200 win...@genial.ms wrote: > Btw., the reason for the 0.10.7 bug report is slow updates there: > https://packages.debian.org/search?keywords=freecol > And there are many other distributions using their packages. > So yeah, it might be better to keep 0.10.7 compatibility, as its too late for > Jessie. Quite so. I admire many things about debian, but their release practice is not one of them. > > > >[Caleb] > > > > FreeCol should take advantage of any features of Java 1.7 that it can. > > We already had 2 incidences of accidentally using a 1.8 method and it took a > quite long > time until someone complained, so one could guess not many are still using > 1.7. > It seems Oracle alrready stopped providing public updates to 1.7 in April? > http://www.oracle.com/technetwork/java/javase/documentation/eol-135779.html Argh, that snuck up on me. I had thought the Java7 EOL was not later this year. Perhaps I am thinking of security-specific updates for which there might be an exception. I was not in a huge rush to move to 8 given that FreeCol is still fairly new to Java7, but it looks like that needs to be moved up the priorities. Java8 has been the default for me for a while, which means the RedHat-derived linuxes are either up to date or getting there. debian had it packaged in unstable last time I looked, and FreeBSD has it, so I think we can assume most unixes at least have a package available to install. Can you comment on the windows situation? IIRC, last time we decided to not worry about XP:-). I will check on the mac situation when I get a chance. > Is there anything in 1.8 that would be useful for us someday? Lambdas look good to me. Lisp will never die. Cheers, Mike Pope pgpdDfMmn_1Y3.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] Release: DHYB
On Fri, 24 Jul 2015 17:08:48 +0200 win...@genial.ms wrote: > > > I did look through all these miscellaneous files we have inside the > > > repository: > > > - I fixed a few minor issues, like wrong version number in docs. > > > - packaging/debian and packaging/gentoo contain ancient files referring > > > to freecol 0.3.0 and Java 1.4. These have been changed by the packagers > > > meanwhile. We may want to delete them as we dont use them or update them > > > to have newer examples for other packagers. > > > > Go for it. > > "A or B?" > "Yes" > *confused* > I guess I'll delete them. Yes, that was what I meant. They were just baggage. >>[developer.tex] > I'd like to add it to the install, as it might attract new contributors. > Lets see how far I get. OK, however lets clear the release-critical things first. > > > Its also weird that some translations are hardcoded in build.xml, when > > > the helper would choose them automatically depending on how complete > > > they are. Is that intentional? > > > > No idea alas. Sounds like it could be improved, but I am not sure it > > buys us much. > > I would think if many translations are missing that would be a release > blocker, but checking that enough are included is also dependent on getting > the installer built first. I am not sure that the hardcoding in build.xml necessarily means that that is an exhaustive list of all translations included. Notice how it uses three letter codes, whereas we are using two letters on the files in data/strings. It might just be setting up a mapping between the 3-letter and 2-letter cases. I can not do a windows install to check this, but I can look inside the java-installer, and AFAICT it contains all the files in the strings directory. This would have been equally broken in 0.11.3 though, so if you do a clean install of 0.11.3 and check what languages are available that should make this clear. > > > - We dont use 2 of the 3 font types we bundle > > > > Which ones? > > Imperator.ttf and Liberation*.ttf in data/base/resources/fonts are unused atm. OK. Liberation was introduced quite a while ago due to complaints about the readability of the standard fonts. I argued mildly against it at the time on the grounds that it was likely to go unmaintained (which turned out to be true:-) and that we should not package fonts but just use what the user had selected for their desktop. In my case, at the time that would have been Liberation:-). That idea failed as no one was sure it could be done portably. Also, as you mention, there was a desire for FreeCol to look the same on all systems. FTR I do not favour that idea either, preferring to give user decisions priority, but it is not that important. However, that was with Java 1.5 IIRC. Good chance the readability problem has solved itself, but I would not be the one to make that call. What I can say is that I have not noticed a problem reading the standard text since your font reworking, and I have rubbish eyesight. So I do not see much to be gained by re-enabling Liberation. IIRC Imperator was in place when I joined the project, so I can not comment much on it. I will try your patch at some point post-release and comment further then. > We seem to have a mechanism for deactivating those fonts for CJK, Cyrillic > and other languages. Which further suggests to me that trying to achieve a uniform appearance everywhere is futile. > > > and I dont know if these > > > should get used again and how to make sure there are no missing glyphs > > > the currently used fonts Java provides have? > > > > I think it is better to use the standard Java fonts where reasonably > > possible, and delegate to them the responsibility of providing a rich > > set of glyphs. AFAICT they are pretty good ATM on linux at least. > > Are you aware of missing glyph problems? > > General cautiousness, as I'm aware most fonts only provide a limited > subset of glyphs. Do you have a program that allows listing which glyphs > for which characters are included in a ttf? ttfdump might be what you want. If I run it on Imperator.ttf I get 1.5M of text which probably means something to someone who knows the ttf format. Let me know if you want the data. I am trying to untangle the mail backlog, so I will respond to your later message about the 3-dot character separately. > I encourage you to backup the SVN once. The art files in there feel really > valuable to me and I plan on using many later. For example, extracting > possibly > layered high res graphics from psd files, where we currently only have ugly > baked > lowres versions in git, which gets blurry on zooming in, should be done > someday. Can I get you to do that, as you know what you want. The "unused" directory would be a good place to put them:-). Speaking of which, in the next release I am hoping to work on the ability to sail to other European ports post-independence, and I always liked bg_europe.jpg and might find a use fo
Re: [Freecol-developers] Release: DHYB
Hi, > > I strongly disagree. Since I joined the project the FreeCol project, > > the minor version has only changed when we make an incompatible change to > > the save game format, in the sense of no longer being able to import games > > written by the previous minor version. ATM we still support the 0.10.x > > format, so there is no urgency to bump the minor version. Furthermore we > > have recent valid bug reports with 0.10.x-originated games attached, so > > there may be user impact to consider. > Your view is definitely the other side of the coin. If FreeCol is using the > SemVar version schema, > breaking API (or in this case save game files), wouldn't matter in beta. If > not (and FreeCol uses > its own version schema), then that what you're saying is fine. > > My view on the matter is that the jump from 0.10.3 to now is so big that it > "deserves" a minor point bump > on that alone. TBH, it's not that big of a deal. IIRC, as I understood the project documentation the number can be changed on new features and is not held back by the compatibility. There is just the rule that compatibility for *at least* the prior minor version should be provided. If the compatibility can be kept for longer, like 3 versions, its even better. So we can go 12.0 to signify additional features (like its done everywhere) and, if we like to, declare in the release notes we keep 0.10.x compatibility for the 0.12.x series. As we are not many people I thought it would be nice to cut down on cruft, but I don't insist on removing the code, as you say its not that bad, Mike. Btw., the reason for the 0.10.7 bug report is slow updates there: https://packages.debian.org/search?keywords=freecol And there are many other distributions using their packages. So yeah, it might be better to keep 0.10.7 compatibility, as its too late for Jessie. Getting them to put a newer version in testing/unstable would still be nice, as many probably use them to be somewhat more up to date. > > >[Caleb] > > > FreeCol should take advantage of any features of Java 1.7 that it can. We already had 2 incidences of accidentally using a 1.8 method and it took a quite long time until someone complained, so one could guess not many are still using 1.7. It seems Oracle alrready stopped providing public updates to 1.7 in April? http://www.oracle.com/technetwork/java/javase/documentation/eol-135779.html Is there anything in 1.8 that would be useful for us someday? Greetings, wintertime -- ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
On Sat, 25 Jul 2015 00:26:05 -0500 Caleb Williams wrote: > Your view is definitely the other side of the coin. If FreeCol is using the > SemVar version schema, breaking API (or in this case save game files), > wouldn't matter in beta. FreeCol's version scheme is already pretty idiosyncratic given the semantics of the leading zero. Nevertheless, while it is fair to describe FreeCol releases to date as beta releases, I would not want to use that as an excuse for causing unnecessary trouble for our users. > > My view on the matter is that the jump from 0.10.3 to now is so big that it > "deserves" a minor point bump on that alone. I think you have just made my point for me. The changes since 0.11.3 are slight in comparison with what went into 0.10.7->0.11.0. Its been a mere 3 months or so since 0.11.3. We were stuck on 0.10.7 for a year and a half! (with more developer activity IIRC). 0.9.5 -> 0.10.0 was about 8 months although that included some alphas. >>[Java 6 features] > Not to my knowledge, I was just stating a general principal that we > shouldn't let some out-dated feature from < 1.6 hold up the project. I am unaware of any such cases. Cheers, Mike Pope pgpWYJVCpcWu3.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] Release: DHYB
> > I strongly disagree. Since I joined the project the FreeCol project, > the minor version has only changed when we make an incompatible change to > the save game format, in the sense of no longer being able to import games > written by the previous minor version. ATM we still support the 0.10.x > format, so there is no urgency to bump the minor version. Furthermore we > have recent valid bug reports with 0.10.x-originated games attached, so > there may be user impact to consider. > Your view is definitely the other side of the coin. If FreeCol is using the SemVar version schema, breaking API (or in this case save game files), wouldn't matter in beta. If not (and FreeCol uses its own version schema), then that what you're saying is fine. My view on the matter is that the jump from 0.10.3 to now is so big that it "deserves" a minor point bump on that alone. TBH, it's not that big of a deal. >[Caleb] > > FreeCol should take advantage of any features of Java 1.7 that it can. > > Quite a few Java 7 improvements have been made (for example use of > the diamond operator, variables in try blocks). Do you have anything in > mind that we are not doing? > Not to my knowledge, I was just stating a general principal that we shouldn't let some out-dated feature from < 1.6 hold up the project. As of this morning though I could not access the website. > That obviously blocks the release, but I also need to delete a few > files there that Caleb cleaned up a while ago from the git master. I did some additional cleaning after the first run through that you uploaded to the site. It appears that the later changes were not uploaded. As for updating the website, it's obviously not as easy (from a one- or two-click point of view) now that's all HTML. For example, the news pages and indexes won't update automatically anymore, so pagination is a problem. At least the following pages need to be updated for a release: - /index.html - /download.html - /news/index.html - /news/releases.html - /news/[all pages for pagination purposes] - /news/releases/[all pages for pagination purposes] RSS feeds may need to be removed, or otherwise also manually updated. Additionally, there may be others. I was mostly unaffected by the outage. Any new work I found to do > could be done in my local git tree. I was the lucky one who had made > the last commit:-) so currency was not a problem. A minor issue is > that my patch queue is now annoyingly large, but a lot of that is just > due to not wanting to touch the strings pre-release. So, I think you > have a slight point, perhaps we should have a nightly backup of the > git tree at a secondary location. Based on my new(ish) experience with GitHub and GitLab, I'm starting to think that hosting our repository off SourceForge may be better. There just seems to be too many issues with SF implementing a lot of things git-related. The ability to add build-support tools such as Travis CI < http://docs.travis-ci.com/user/languages/java/> and Scrutinizer CI < https://scrutinizer-ci.com/docs/build/environment#java> to GitHub are also a huge plus as well. It appears that both can support OpenJDK versions and Oracle versions. That could help suss out some issues with different platforms. Best, -- *Caleb R. Williams* -- ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
On Fri, 24 Jul 2015 21:56:28 +0200 win...@genial.ms wrote: > it crossed my mind that some time ago people were complaining > about the Mac builds not working. AFAICT that was due to Apple's somewhat adversarial treatment of Java. There were follow ups saying "install the package and it works". I have definitely sighted 0.11.3 working on Macs. > Another thought I had was, that the codebase collected many > compatibility hacks from the overly long 0.10.x series. > I did a search and there are about 243 hacks for 0.10.x and > about 141 hacks for 0.11.x already. > The 0.11.x series already had 3 patch releases for 0.11.0, which > is in line with how it was done until 0.9.x. I think that is just a historical accident. > We have new features implemented in addition to all the bugfixes, > which also suggests increasing the minor version. > So, I would like going to 0.12.0 directly. > After the release we could drop 0.10.x compatibility and get rid > of 2/3 of the hacks. I strongly disagree. Since I joined the project the FreeCol project, the minor version has only changed when we make an incompatible change to the save game format, in the sense of no longer being able to import games written by the previous minor version. ATM we still support the 0.10.x format, so there is no urgency to bump the minor version. Furthermore we have recent valid bug reports with 0.10.x-originated games attached, so there may be user impact to consider. As to the number of accumulated backwards compatibility hacks, the important question is whether they are impeding progress or not. Speaking as the main instigator of the last minor version bump, believe me, if you think the 0.10.x compatibility code is annoying, be thankful you did not have to work with the 0.9.x stuff! We are nowhere nearly as badly off as things were in 0.10.6+. However in the end what prompted the last bump was the existence of two clusters of bugs that were outright unfixable without an incompatible change to the save game format, not mere developer discomfort. This lead to the tile caching and equipment->role changes. Note that there is reporting bias in the numbers. I only started to add the @compat annotations late in the 0.10.x series, but since then I have been fairly meticulous about them. So the number of 0.10.x hacks is probably lower than actually exist, whereas the 0.11.x ones are close to accurate but include trivial changes. Returning then to the question of progress --- I just did a quick sample of the annotations, and found they were highly concentrated in the serialization code, which is not a huge surprise. This is not an area needing a lot of work ATM IMHO, given that it was almost totally revised for 0.11.0. So I have to ask if there is a specific problem that the compatibility code is causing? >[Caleb] > FreeCol should take advantage of any features of Java 1.7 that it can. Quite a few Java 7 improvements have been made (for example use of the diamond operator, variables in try blocks). Do you have anything in mind that we are not doing? Cheers, Mike Pope pgpJWpcw8S3mF.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] Release: DHYB
100% agree. FreeCol is still technically in beta, some removal of dead weight code should be considered, if not encouraged. FreeCol should take advantage of any features of Java 1.7 that it can. On Jul 24, 2015 2:56 PM, wrote: > Hi, > > it crossed my mind that some time ago people were complaining > about the Mac builds not working. I did not pay much attention > back then, as I don't have one and don't know about them, but > I thought I should remind you. > > Another thought I had was, that the codebase collected many > compatibility hacks from the overly long 0.10.x series. > I did a search and there are about 243 hacks for 0.10.x and > about 141 hacks for 0.11.x already. > The 0.11.x series already had 3 patch releases for 0.11.0, which > is in line with how it was done until 0.9.x. > We have new features implemented in addition to all the bugfixes, > which also suggests increasing the minor version. > So, I would like going to 0.12.0 directly. > After the release we could drop 0.10.x compatibility and get rid > of 2/3 of the hacks. > > > Regards, > > wintertime > > > -- > ___ > Freecol-developers mailing list > Freecol-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freecol-developers > -- ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
Hi, it crossed my mind that some time ago people were complaining about the Mac builds not working. I did not pay much attention back then, as I don't have one and don't know about them, but I thought I should remind you. Another thought I had was, that the codebase collected many compatibility hacks from the overly long 0.10.x series. I did a search and there are about 243 hacks for 0.10.x and about 141 hacks for 0.11.x already. The 0.11.x series already had 3 patch releases for 0.11.0, which is in line with how it was done until 0.9.x. We have new features implemented in addition to all the bugfixes, which also suggests increasing the minor version. So, I would like going to 0.12.0 directly. After the release we could drop 0.10.x compatibility and get rid of 2/3 of the hacks. Regards, wintertime -- ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
Sorry, forgot to attach the diff for activating the fonts. diff --git a/data/base/resources.properties b/data/base/resources.properties index d20ca31..69a0f75 100644 --- a/data/base/resources.properties +++ b/data/base/resources.properties @@ -2,9 +2,9 @@ # Decorative font to use for panel headers. font.header=resources/fonts/ShadowedBlack.ttf # Font to use for normal text. -font.normal=urn:font:Serif-PLAIN-12 +font.normal=resources/fonts/LiberationSerif-Regular.ttf # Deliberately simple font. -font.simple=urn:font:Dialog-PLAIN-12 +font.simple=resources/fonts/Imperator.ttf # Signature for Declaration of Independence animatedfont.signature=resources/fonts/signature.faf -- ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
Hi, > Gesendet: Freitag, 24. Juli 2015 um 11:35 Uhr > Von: "Michael T. Pope" > An: win...@genial.ms > Cc: freecol-developers@lists.sourceforge.net > Betreff: Re: [Freecol-developers] Release: DHYB > > On Thu, 23 Jul 2015 15:48:51 +0200 > win...@genial.ms wrote: > > as I'd really like to see a release soon > > Its imminent. I have been happily playtesting during the outage, and > only found one outright bug, now fixed. I think we are nearly ready > to go. As of this morning though I could not access the website. > That obviously blocks the release, but I also need to delete a few > files there that Caleb cleaned up a while ago from the git master. I guess we should give it some more days to iron out the remaining issues and fix the installer. Meanwhile the SF people hopefully have everything running again smoothly. > > I did look through all these miscellaneous files we have inside the > > repository: > > - I fixed a few minor issues, like wrong version number in docs. > > - packaging/debian and packaging/gentoo contain ancient files referring > > to freecol 0.3.0 and Java 1.4. These have been changed by the packagers > > meanwhile. We may want to delete them as we dont use them or update them > > to have newer examples for other packagers. > > Go for it. "A or B?" "Yes" *confused* I guess I'll delete them. > > - I stumbled upon a forum post saying jsmooth does not support 64bit, > > but dont know if its true. So testing the installation again would be > > nice before a release (without Java installed and with only 64bit Java > > installed, though remember trying it when we had the izpack problem. > > Maybe a switch to something else, maybe Launch4j, might be a good > > idea. > > Caleb was having trouble a while back (BR#2790), which may have been > fixed by git.428e836. You tell me --- are we seeing successful 64-bit > windows installs with 0.11.3? If so, jsmooth is presumably still > operating. I do not have much useful to contribute here. You are > clearly in a much better position to work on this. I want to be sure and try it before release, though its likely it can find the 64bit java and works. Though that is dependant on getting the installer to build, first. > > There I wondered why the developer.tex is not built, should we add it > > to the build.xml where it is missing? > > Whoever added developer.tex did not make it part of the release > upload. I suspect the idea is that developers have a source tree and > can run TeX on it locally. I'd like to add it to the install, as it might attract new contributors. Lets see how far I get. > > - Building the installer failed, as there is something wrong with > > the build.xml, it can not find the translation helper: > > [java] Could not find net.sf.freecol.tools.InstallerTranslations. > > Make sure you have it in your classpath > > Yes, there is text somewhere (developer.tex?) saying to ignore this. > I do not know what the story is there. Well, that is the biggest release blocker unless the Windows installer can be cross-compiled from Linux. > > Its also weird that some translations are hardcoded in build.xml, when > > the helper would choose them automatically depending on how complete > > they are. Is that intentional? > > No idea alas. Sounds like it could be improved, but I am not sure it > buys us much. I would think if many translations are missing that would be a release blocker, but checking that enough are included is also dependent on getting the installer built first. > > - All kinds of unnecessary things get copied to the dist directory, but > > not sure if they then get packaged as that did not work. We may want > > to prevent this. > > Quite so. Another thing to check after the installer is building ccorrectly. > > - We have some asset files which are unused. Some may be deleted and some > > moved to some other folder to prevent them from getting packaged. > > Then I could clean up references to them in resources.properties. > > If they are unused feel free to delete them. We can always get them > back. I'll do. > > - We dont use 2 of the 3 font types we bundle > > Which ones? Imperator.ttf and Liberation*.ttf in data/base/resources/fonts are unused atm. > > and I dont know if these > > should get used again and how to make sure there are no missing glyphs > > the currently used fonts Java provides have? > > I think it is better to use the standard Java fonts where reasonably > possible, and delegate to them the responsibility of providing a rich > set of glyphs. AFAICT they are pretty good ATM on linux at least. >
Re: [Freecol-developers] Release: DHYB
On Thu, 23 Jul 2015 15:48:51 +0200 win...@genial.ms wrote: > as I'd really like to see a release soon Its imminent. I have been happily playtesting during the outage, and only found one outright bug, now fixed. I think we are nearly ready to go. As of this morning though I could not access the website. That obviously blocks the release, but I also need to delete a few files there that Caleb cleaned up a while ago from the git master. > I did look through all these miscellaneous files we have inside the > repository: > - I fixed a few minor issues, like wrong version number in docs. > - packaging/debian and packaging/gentoo contain ancient files referring > to freecol 0.3.0 and Java 1.4. These have been changed by the packagers > meanwhile. We may want to delete them as we dont use them or update them > to have newer examples for other packagers. Go for it. > - I tried to find which version of jsmooth (the exe wrapper for Windows) > we are using and no file contained a version number. Later I found a > commit message saying we use 0.99-7 already, which is the "newest" > version. In reality this is a dead project not updated since 2007, > with no commits in CVS since 2008 (they really use CVS, but Sourceforge > did not restore their repo up until today). CVS. How quaint. > - I stumbled upon a forum post saying jsmooth does not support 64bit, > but dont know if its true. So testing the installation again would be > nice before a release (without Java installed and with only 64bit Java > installed, though remember trying it when we had the izpack problem. > Maybe a switch to something else, maybe Launch4j, might be a good > idea. Caleb was having trouble a while back (BR#2790), which may have been fixed by git.428e836. You tell me --- are we seeing successful 64-bit windows installs with 0.11.3? If so, jsmooth is presumably still operating. I do not have much useful to contribute here. You are clearly in a much better position to work on this. > - I tried building a Windows installer and even got the Freecol.pdf > to get built for the first time, after installing MiKTeX 64bit net. Cool. So we are one step closer to being able to do a release build on windows again. > There I wondered why the developer.tex is not built, should we add it > to the build.xml where it is missing? Whoever added developer.tex did not make it part of the release upload. I suspect the idea is that developers have a source tree and can run TeX on it locally. > - Building the installer failed, as there is something wrong with > the build.xml, it can not find the translation helper: > [java] Could not find net.sf.freecol.tools.InstallerTranslations. > Make sure you have it in your classpath Yes, there is text somewhere (developer.tex?) saying to ignore this. I do not know what the story is there. > Its also weird that some translations are hardcoded in build.xml, when > the helper would choose them automatically depending on how complete > they are. Is that intentional? No idea alas. Sounds like it could be improved, but I am not sure it buys us much. > - All kinds of unnecessary things get copied to the dist directory, but > not sure if they then get packaged as that did not work. We may want > to prevent this. Quite so. > - We have some asset files which are unused. Some may be deleted and some > moved to some other folder to prevent them from getting packaged. > Then I could clean up references to them in resources.properties. If they are unused feel free to delete them. We can always get them back. > - We dont use 2 of the 3 font types we bundle Which ones? I have never been in favour of bundling fonts, unless they are not readily available (which would be the case with our "header" font I assume). If we can clean these up that would be a win. > and I dont know if these > should get used again and how to make sure there are no missing glyphs > the currently used fonts Java provides have? I think it is better to use the standard Java fonts where reasonably possible, and delegate to them the responsibility of providing a rich set of glyphs. AFAICT they are pretty good ATM on linux at least. Are you aware of missing glyph problems? As usual, I would not be exercising the accented characters much, outside the national colony names. However I have been experimenting with some annotations for my tweaks to reports like trade and colony --- we currently sometimes append a "*" for colonies with a customs house, but it would be nice to be able to see other interesting features, like the stockade-type or shipyard-type buildings. So I have a patch which uses some obscure unicode symbols, and as yet I have not found anything missing in the 4-hex-digit range when using the default text font. The newer stuff in the 1 range are not well supported though. > - Still need to download the jsmooth GUI helper and check all options, > as I found suspicious references to Java 1.2 and 1.4 in some config file
Re: [Freecol-developers] Release: DHYB
Hi, as I'd really like to see a release soon I did look through all these miscellaneous files we have inside the repository: - I fixed a few minor issues, like wrong version number in docs. - packaging/debian and packaging/gentoo contain ancient files referring to freecol 0.3.0 and Java 1.4. These have been changed by the packagers meanwhile. We may want to delete them as we dont use them or update them to have newer examples for other packagers. - I tried to find which version of jsmooth (the exe wrapper for Windows) we are using and no file contained a version number. Later I found a commit message saying we use 0.99-7 already, which is the "newest" version. In reality this is a dead project not updated since 2007, with no commits in CVS since 2008 (they really use CVS, but Sourceforge did not restore their repo up until today). - I stumbled upon a forum post saying jsmooth does not support 64bit, but dont know if its true. So testing the installation again would be nice before a release (without Java installed and with only 64bit Java installed, though remember trying it when we had the izpack problem. Maybe a switch to something else, maybe Launch4j, might be a good idea. - I tried building a Windows installer and even got the Freecol.pdf to get built for the first time, after installing MiKTeX 64bit net. There I wondered why the developer.tex is not built, should we add it to the build.xml where it is missing? - Building the installer failed, as there is something wrong with the build.xml, it can not find the translation helper: [java] Could not find net.sf.freecol.tools.InstallerTranslations. Make sure you have it in your classpath Its also weird that some translations are hardcoded in build.xml, when the helper would choose them automatically depending on how complete they are. Is that intentional? - All kinds of unnecessary things get copied to the dist directory, but not sure if they then get packaged as that did not work. We may want to prevent this. - We have some asset files which are unused. Some may be deleted and some moved to some other folder to prevent them from getting packaged. Then I could clean up references to them in resources.properties. - We dont use 2 of the 3 font types we bundle and I dont know if these should get used again and how to make sure there are no missing glyphs the currently used fonts Java provides have? - Still need to download the jsmooth GUI helper and check all options, as I found suspicious references to Java 1.2 and 1.4 in some config file and am not sure it these are just for the wrapper or the game. - Also need to check if izpack can be updated, as I remember there've been new versions of it, which may help with the problems we had with it. It'd be nice if you had answers for all my questions. PS: The SF outage made me think it may be nice to not depend on only one website. I had found someone had uploaded most of the newest commits in Freecol git to github, but many other things I needed were only on SF. If something stops working you suddenly see how many projects have their website and downloads only there. You sure have backups of the complete SVN and bug/feature trackers? Greetings, wintertime -- ___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
Since the last post on this, implementations for PF#4 and PF#5 have been committed and there have been translation updates. So we are mostly release-ready. The InformationPanel problem that wintertime is looking at is about all I definitely know about that is worth waiting for a fix for, however urgency is low because I am about to do a bunch of play testing to check for any remaining message-rename problems (and as usual make sure the REF is not getting confused:-). "Would be nice" issues: - There are a few "interesting" warnings coming out of the AI regression tests, but no performance impact. I plan to look at these in slow time. The majority of AI tests are completing warning-free. - No progress has occurred with America_large. - I am tempted to close BR#2796, as there have been no recent sightings which hopefully means the experimental fix worked. However, it is a nasty bug. Has anyone seen it lately? - I have a bunch of boring spec canonicalization patches underway. They may or may not make the release. Looking ahead I am anticipating a big push on remaining PFs, particularly PF#14, PF#23, PF#24, PF#26, PF#34, PF#36, PF#37, PF#39, PF#45, PF#54, PF#59, PF#67. Some have WWC1D blockages, but there may be progress to make nevertheless. Cheers, Mike Pope pgpyp1PSvIbjT.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] Release: DHYB
On Sat, 9 May 2015 11:42:25 +0930 "Michael T. Pope" wrote: > I realize I intended to mention the release status in a recent message but > forgot to add it on. The status is: `Dont Hold Your Breath'. We need to > wait for the translators to absorb the big message renaming I did a while > back. Just heard from the translation wranglers that the rename merge has been done, which looks like it has hit the repo in git.6e7cbc9. They have marked the ones that changed as "fuzzy" which I believe means that the existing words remain in the release but are flagged to translators as needing to be looked at again. So I think we should wait a bit longer and see if this provokes some translation activity --- there should be some backlog as I did change quite a few texts recently. Nevertheless, the main reason for release delay is now gone. The rest is mostly "Would be nice". I have started on PF#5 which I want to finish. If anyone has time, it would be good to know if BR#2813 is still broken and if PF#6 is working. The main thing I would like to see is the America_large clean up. Cheers, Mike Pope pgpVys3LxiQpe.pgp Description: OpenPGP digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
We have made some good progress, and all recent bugs are either fixed or needing info. The outstanding issues are now: On Sat, 9 May 2015 11:42:25 +0930 "Michael T. Pope" wrote: > BR#2836 TileInfoPanel glitched This is now waiting for artwork so as to make it big enough for languages with long texts. There is also a Java library issue. Not a release blocker. > BR#2813 Lack of Tools/building supplies not reported to us Still unclear if this is still broken. > BR#2806 Information on corner stopped showing Awaiting information, not a release blocker. > PF#4 King should provide military units when declares a war First cut done. Still has issues, hopefully resolved shortly. > PF#5 Indians in independence war Next on my list > PF#6 Danish mercenaries during revolution Awaiting dis/confirmation that it is done. > PF#23 With bread and salt... Awaiting action. > PF#34 Native Annoyance level doesn't go down Awaiting action > America_large cleanup Awaiting action Cheers, Mike Pope pgpT8olugX9Bg.pgp Description: OpenPGP digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
> > BR#2847 Panels/GUI No longer working in Multiplayer > Caleb, are you still seeing this or did the fix work? Multiplayer seems to load just fine now, graphically speaking. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
Hi,
> >[BR#2836 Chossing to land one colonist lands both]
> There are several dialogs indeed, but they are all distinct for me.
>
I feel like there is a communication problem, but I dont know how to
explain it any better. The image of the dialog is in the reply
to the BR.
> > - right-click the tile and see both had moved there from the ship
>
> Not for me. The double unload may well be a side-effect of the dialog
> doubling.
>
The bug was there before some change added the dialog doubling.
> >[BR#2839 TileInfoPanel glitched]
> > That part is from 2 useless empty lines between Defence and Movement, which
> > for some reason happens for mountain and ocean tiles, but not others.
>
> I do not see that with the current git. The defence and movement lines
> are positioned quite closely under the centered tile type +
> improvements line for hills.
I posted pictures about the problem with the gap and missing goods icons
on the BR. It is there in newest git version.
> What I notice is that if you click on a
> non-{Hills,Mountain} tile and then switch to a {Hills,Mountain} tile, in
> the latter case the icon is positioned lower in the panel. It looks like
> there is empty space at the top of the elevated terrain. Is this
> something to do with the way they are overlaid on the main map?
I thought I wrote this already? Tile overlays use images with bigger height
than normal tiles. The images are then drawn with their upper-left at same
position, making the tile part of bigger images show lower.
If the images could be aligned on lower left corner that would be fixed.
> Apart from that, now with our combined recent fixes, I am not seeing
> anything else broken on the InfoPanel. Does anyone else have any
> problems?
Lets hope tiles with fish resource and fish bonus from beach and fish
bonus from river fits on one line with translated text.
PS: Caleb, if you do extract images:
Coat of arms and founding fathers are what I would look at first.
It would be nice if you can look before doing that if there are separate
image layers and you could save these separately in png with rgba.
FF should all be same size already.
Next would be units, they might require more work to find all images
and check if they are aligned in same way or need cropping.
Greetings,
wintertime
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
On Sun, 10 May 2015 15:25:36 +0200
win...@genial.ms wrote:
>[BR#2836 Chossing to land one colonist lands both]
> I just:
> - loaded savegame included in BR
> - moved the ship to the position on picture
> - used the keypad on keyboard to attempt moving the ship to the landtile you
> see the colonists on in the picture
> - saw how the dialog, which you can see in the picture on the reply on the BR
> opened up
> - clicked the button describing the soldier (or the pioneer)
> - all kinds of dialogs pop up twice
There are several dialogs indeed, but they are all distinct for me.
> - right-click the tile and see both had moved there from the ship
Not for me. The double unload may well be a side-effect of the dialog
doubling.
>[BR#2839 TileInfoPanel glitched]
> That part is from 2 useless empty lines between Defence and Movement, which
> for some reason happens for mountain and ocean tiles, but not others.
I do not see that with the current git. The defence and movement lines
are positioned quite closely under the centered tile type +
improvements line for hills. What I notice is that if you click on a
non-{Hills,Mountain} tile and then switch to a {Hills,Mountain} tile, in
the latter case the icon is positioned lower in the panel. It looks like
there is empty space at the top of the elevated terrain. Is this
something to do with the way they are overlaid on the main map?
Apart from that, now with our combined recent fixes, I am not seeing
anything else broken on the InfoPanel. Does anyone else have any
problems?
Cheers,
Mike Pope
pgpQPoVC6gSLN.pgp
Description: OpenPGP digital signature
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
Hi, I'm replying to both mails at once. > > > BR#2839 Chossing to land one colonist lands both > > > ... > > Did you retest after my latest reply? It is only happening when the dialog > > show on the provided image is clicked. > > Sorry, I am not sure what you mean by the above. Can you give me a > detailed description of how you trigger the bug? I have not deliberately > been testing this, but I do use the disembark dialog fairly often in > normal testing and have seen nothing lately. However IIRC I have only > ever seen this problem happen twice (and in both cases I was not sure that > it had happened), so its likely a Java-instance-sensitive race. I just: - loaded savegame included in BR - moved the ship to the position on picture - used the keypad on keyboard to attempt moving the ship to the landtile you see the colonists on in the picture - saw how the dialog, which you can see in the picture on the reply on the BR opened up - clicked the button describing the soldier (or the pioneer) - all kinds of dialogs pop up twice - right-click the tile and see both had moved there from the ship > > > BR#2836 TileInfoPanel glitched > > Only remaining part, which could be fixed sooner, would be the missing goods > > icons for mountains/oceans, where I did not find out why that was before > > writing the issue. > > OK, sounds like we have artwork blockages. I will see what else can be > done, but BR#2836 is definitely not a release blocker. > That part is from 2 useless empty lines between Defence and Movement, which for some reason happens for mountain and ocean tiles, but not others. This probably pushes the goods icons showing the tile production below the cutoff point in the TileInfoPanel and so they can be seen only on other tiles. > >[BR#2836 TileInfoPanel glitched] > > > I recently saw there is only one of the fish resource > > > infos shown in the message for one tile, have there been changes? > > I am still seeing double bonuses where a river meets the coast. AFAICT > this is correct. > I thought the info about the fish bonus near beach was missing, but is shown now. If 2 or more boni happen to be on a single tile its cut off now, cause of the larger font. > I have added a routine to split text and used it in the parts of InfoPanel. > This has fixed the problems I was seeing in UnitInfoPanel, but testing is > limited. > I think we have something in Utility for a larger text area with automatic linefeeds, but its probably not appropriate for using it in that tiny space. > The tiny font in TileInfoPanel was just too small, so I have dropped it > for now in attempt to make it work with a normal font. There has > been some unification of the texts, but opportunities are limited > because we have to be quite terse there still, unlike in TilePanel. > I may yet add the defence and movement information to TilePanel. Part of > the fix has been to shorten the defence and movement texts, which will not > be showing up in translation yet, so expect them to be truncated in > non-vanilla locales. The placement of the icon seems flakey, hills tiles > in particular are truncated at the bottom. Do you know what is happening > there? What I would like is for the icon to be a bit smaller, > is there a way to get that with createTileImageWithBeachBorderAndItems? > The problem with the Hills, Mountains and Forests was also caused by the larger font. It basically needs more space and pushes the image down, far enough for parts of it getting cut off. The panel is somehow smaller than the skin, which gets separately drawn. You may find a way to get the unused area on the edge of screen at bottom and right side smaller. Though I now added a resized image of the skin, which is slightly blurred, but worth it, as this got a usable area of about 305x160 (or maybe 5 pixel smaller), which is about 30 pixel more than it had been before. Thats enough for the mountains, at least. Mountains are 96 pixel high, forests 84 and normal tiles only 64; I added the numbers near beginning of the ImageLibrary class. I would not make the tile image smaller, as that would need a third MapViewer, while I was hoping of someday eliminating the second providing the 1:1 images for panels and moving necessary code to ImageLibrary or a new class. You could resize it after creating the image, but I tried to eliminate code doing such from the codebase, as it goes contrary to the caching in ResourceManager, reduces image quality and costs cpu time. > The EndTurnPanel has also been kicked, so far without incident. > Nice. Greetings, wintertime -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/29042051
Re: [Freecol-developers] Release: DHYB
On Sun, 10 May 2015 19:43:20 +0930 "Michael T. Pope" wrote: >[BR#2836 TileInfoPanel glitched] > > I recently saw there is only one of the fish resource > > infos shown in the message for one tile, have there been changes? I am still seeing double bonuses where a river meets the coast. AFAICT this is correct. I have added a routine to split text and used it in the parts of InfoPanel. This has fixed the problems I was seeing in UnitInfoPanel, but testing is limited. The tiny font in TileInfoPanel was just too small, so I have dropped it for now in attempt to make it work with a normal font. There has been some unification of the texts, but opportunities are limited because we have to be quite terse there still, unlike in TilePanel. I may yet add the defence and movement information to TilePanel. Part of the fix has been to shorten the defence and movement texts, which will not be showing up in translation yet, so expect them to be truncated in non-vanilla locales. The placement of the icon seems flakey, hills tiles in particular are truncated at the bottom. Do you know what is happening there? What I would like is for the icon to be a bit smaller, is there a way to get that with createTileImageWithBeachBorderAndItems? The EndTurnPanel has also been kicked, so far without incident. Cheers, Mike Pope pgpBbIjEX1KMJ.pgp Description: OpenPGP digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
Re: [Freecol-developers] Release: DHYB
win...@genial.ms wrote:
> > BR#2839 Chossing to land one colonist lands both
> > ...
> Did you retest after my latest reply? It is only happening when the dialog
> show on the provided image is clicked.
Sorry, I am not sure what you mean by the above. Can you give me a
detailed description of how you trigger the bug? I have not deliberately
been testing this, but I do use the disembark dialog fairly often in
normal testing and have seen nothing lately. However IIRC I have only
ever seen this problem happen twice (and in both cases I was not sure that
it had happened), so its likely a Java-instance-sensitive race.
> > BR#2836 TileInfoPanel glitched
> > Another one I would like to assign to wintertime as the now offical
> > GUI expert:-).
> >
> I was under the impression this is stalled on someone providing a better
> image for the panel skin
Fair enough.
> or you unifying the messages with the other panel, to make more space?
OK, I looked at that and was not convinced there was a big win to be had
there, but I will check again.
> I recently saw there is only one of the fish resource
> infos shown in the message for one tile, have there been changes?
Nothing deliberate:-). The message clean up touched so much code that it
is entirely possible a lurking bug got swept away.
> Only remaining part, which could be fixed sooner, would be the missing goods
> icons for mountains/oceans, where I did not find out why that was before
> writing the issue.
OK, sounds like we have artwork blockages. I will see what else can be
done, but BR#2836 is definitely not a release blocker.
> > BR#2820 Alt-Enter empty panel glitch
> > Another one I can not reproduce. Any updates?
> >
> Just the reply I had added to the report recently.
> I dont know how to fix it and its blocked from happening with your change.
Good to know that the mitigation worked.
> Fullscreen mode is too annoying to use anyway, cause of the unsupported use
> of JDialog causing problems (sometimes behind the window, sometimes the
> main window minimizing, depending on Java version or phase of moon).
I should probably switch to using full screen then:-). Java seems to be a
lot better maintained under linux than our other targets. OTOH, it has
had a lot of problems...
> > BR#2806 Information on corner stopped showing
> > Still unclear when this occurs.
> >
> I think thats low priority as its happening only rarely. I would just wait
> for people reporting additional sightings and more info.
Agreed.
> I remember looking through most PF and thinking near everything is
> blocked on Col1 info, other things I dont know enough about the code or the
> gameplay of Col1, few remaining things are useless busywork like #2.
PF#2 is somewhat legitimate from a compatibility viewpoint, which is why
no one has closed it, but equally, so far no developer has shown any
interest. I do not intend to work on it, and do not regard it as a
FreeCol 1.0 release blocker.
You are correct that a lot of PFs are blocked needing Col1-info, and these
should have "open-{WWC1D,need-info}" status. There are still quite a
few that are merely "open", which should be unblocked. I admit some of
these are hard though. Some are both (e.g. PF#9) but I may yet at least
make a trial implementation.
> >[America_large]
> IIRC there had been settlements contained inside the America map, but
> for some reason (bug-circumvention???) the info was deleted from it.
I forget the details. There was a fail at one point when either the
map format changed or a bunch of fixes to the map were made. I was
probably the offender. However the old settlement positions were not
brilliant either --- there were settlements on 1-tile islands and the
number of settlements was quite low. I suspect we decided at the time
that dropping the fixed settlements was the lesser fail, as FreeCol was
by then auto-generating them decently. No one has noticed and/or
complained so it looks like we made a reasonable call.
> I guess it woud be easier to check out that old FreeCol version,
> then transplant the interesting xml tags manually into the current map.
Alas no. The format has changed, and you have to remap id numbers so it
is not just a simple cut and paste. I have found some notes I made last
time I looked at this --- apparently git.12e5780 should have settlements
in America_large. I extracted their positions and info as you suggest and
wrote a hack to put them back into a map (attached[1]), but was
dissatisfied with the result and dropped the project. Anyone interested
is welcome to use the attached hack, but even if it can be made to work,
expect to still have to spend time in the map editor cleaning up the
result... and if the number of settlements is a concern to you as I think
it should be, it is probably easier to work from a current well-populated
game/map.
Cheers,
Mike Pope
[1] The code looks like it should work, but there
Re: [Freecol-developers] Release: DHYB
Hi, > Gesendet: Samstag, 09. Mai 2015 um 04:12 Uhr > Von: "Michael T. Pope" > An: "FreeCol Developers" > Betreff: [Freecol-developers] Release: DHYB > > Nevertheless we should try to keep the tree in reasonable shape. The > bug report list is quite good ATM. As usual we have many bugs languishing > in "Need-Info" state awaiting further information (I would especially like > WWC1D help with BR#2824), but excluding those I do not see anything open > that I would consider a release-blocker. What Would-Be-Nice to see > settled are: > Most of the bigger projects I wanted to do are complete now and I'll probably put less time in for a while. I'm waiting for people to test the resizable GUI and reporting cut off text, most likely in some dialogs. If more higher res images get available I could also do some changes to the code to have these used. The river-maker and forest-maker look like they could help with this, though they somehow load images and modify them and I'm dont know about the preconditions. A few code changes will also be necessary to generate additional images in doubled resolution. AFAIK, Michael Vehrs created them and if he could provide some info it would be of much help. ;) It would also be nice to know if he still got some original larger images of the coat of arms. If other former contributors could tell more info about where other images came from or even got some base-images still, it would be of much help. Some are still in SVN, but need help of a person owning/knowing Photoshop to get highres versions extracted. > BR#2839 Chossing to land one colonist lands both > I can probably fix this, but I can not reproduce the failure, so I can > not test the fix. wintertime reports seeing the failure, can I assign > this to you, or would you prefer I went ahead with the fix and you just > provide non/confirmation? > Did you retest after my latest reply? It is only happening when the dialog show on the provided image is clicked. > BR#2836 TileInfoPanel glitched > Another one I would like to assign to wintertime as the now offical > GUI expert:-). > I was under the impression this is stalled on someone providing a better image for the panel skin or you unifying the messages with the other panel, to make more space? I recently saw there is only one of the fish resource infos shown in the message for one tile, have there been changes? Only remaining part, which could be fixed sooner, would be the missing goods icons for mountains/oceans, where I did not find out why that was before writing the issue. > BR#2820 Alt-Enter empty panel glitch > Another one I can not reproduce. Any updates? > Just the reply I had added to the report recently. I dont know how to fix it and its blocked from happening with your change. Fullscreen mode is too annoying to use anyway, cause of the unsupported use of JDialog causing problems (sometimes behind the window, sometimes the main window minimizing, depending on Java version or phase of moon). > BR#2806 Information on corner stopped showing > Still unclear when this occurs. > I think thats low priority as its happening only rarely. I would just wait for people reporting additional sightings and more info. > That takes us back into pre-0.11.3 bugs. Moving on, it would be even > nicer if we could knock off a PF or two. > I remember looking through most PF and thinking near everything is blocked on Col1 info, other things I dont know enough about the code or the gameplay of Col1, few remaining things are useless busywork like #2. > Also on my TODO list is the America_large map. Unlike the other maps it > lacks predefined native settlements. I can easily start a new > America_large game, save it, and edit it down to the reduced format output > by the map generator. However the settlement placement is still > historically inept --- the Inca need to stay out of North America, the > Arawak should be in the Caribbean rather than the Apache, capitals (Qosco, > Teocuitlatlan, Onondaga) should be where they actually were, etc. Any > volunteer with patience interested in spending a while in the map editor > to clean up America_large? I can attach a suitable first cut if requested. > IIRC there had been settlements contained inside the America map, but for some reason (bug-circumvention???) the info was deleted from it. I guess it woud be easier to check out that old FreeCol version, then transplant the interesting xml tags manually into the current map. Even just copying the settlement coordinates and ownership info would most likely be faster than researching this info anew. Greetings, wintertime -- One dashboard for servers and applications across Physical-Virtual-
[Freecol-developers] Release: DHYB
I realize I intended to mention the release status in a recent message but forgot to add it on. The status is: `Dont Hold Your Breath'. We need to wait for the translators to absorb the big message renaming I did a while back. There is no problem with it, just a lack of time from the translatewiki person I have been talking to about doing things the right way. After he is done, we should probably wait one more commit from translatewiki as there are some associated non-simple-rename changes (as wintertime noticed in a recent BR). Translatewiki commits are outside our control so there is no obvious date I can give for now. Nevertheless we should try to keep the tree in reasonable shape. The bug report list is quite good ATM. As usual we have many bugs languishing in "Need-Info" state awaiting further information (I would especially like WWC1D help with BR#2824), but excluding those I do not see anything open that I would consider a release-blocker. What Would-Be-Nice to see settled are: BR#2847 Panels/GUI No longer working in Multiplayer Caleb, are you still seeing this or did the fix work? BR#2839 Chossing to land one colonist lands both I can probably fix this, but I can not reproduce the failure, so I can not test the fix. wintertime reports seeing the failure, can I assign this to you, or would you prefer I went ahead with the fix and you just provide non/confirmation? BR#2836 TileInfoPanel glitched Another one I would like to assign to wintertime as the now offical GUI expert:-). BR#2820 Alt-Enter empty panel glitch Another one I can not reproduce. Any updates? BR#2813 Lack of Tools/building supplies not reported to us I saw this work recently. Caleb was looking at it a while back --- any more non/sightings of this one? BR#2806 Information on corner stopped showing Still unclear when this occurs. That takes us back into pre-0.11.3 bugs. Moving on, it would be even nicer if we could knock off a PF or two. - Working from the oldest first, the obvious ones where I am familiar with the code and we are not blocked in WWC1D are PF#4 and #5, so I have taken ownership of these and will tackle them as soon as I finish with a couple of outstanding AI failures. - I believe Michael implemented PF#6 several releases ago, but confirmation this is working would be welcome. - The next relatively straightforward one is PF#23 which I commend to your attention, although it will involve the AI and I generally warn against working on the AI:-). - PF#34 is partly mitigated now that there is an option controlling the effect of missions (thanks to Fenyo). What would be nice is to make *all* the hardcoded native alarm magic numbers into options. This is rather tedious work, but straightforward. Of course this does not resolve the WWC1D issue here, but it would make that easier for a player to experiment and report back some good numbers to use, which would allow us to close this PF. Also on my TODO list is the America_large map. Unlike the other maps it lacks predefined native settlements. I can easily start a new America_large game, save it, and edit it down to the reduced format output by the map generator. However the settlement placement is still historically inept --- the Inca need to stay out of North America, the Arawak should be in the Caribbean rather than the Apache, capitals (Qosco, Teocuitlatlan, Onondaga) should be where they actually were, etc. Any volunteer with patience interested in spending a while in the map editor to clean up America_large? I can attach a suitable first cut if requested. Cheers, Mike Pope pgprT5YPplrSR.pgp Description: OpenPGP digital signature -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
