Hi, > Gesendet: Freitag, 24. Juli 2015 um 11:35 Uhr > Von: "Michael T. Pope" <mp...@computer.org> > 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. > 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? > 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 1XXXX range are not > well supported though. Please, try the attached diff, it activates the unused fonts. I tried it and at least German äöüßÄÖÜ and some characters with ´` and ^ are included. If we use them permanently I would need to change a bit of font code to use the premade bold/italic ttf files for liberation, as that might be better quality than Java manipulating the normal font at runtime. We seem to have a mechanism for deactivating those fonts for CJK, Cyrillic and other languages. The data/base/resources_*.properties files overwrite the font settings with empty keys. You could try deleting some of these and check these languages with and wihout the files. One advantage of providing fonts would be less dependence on system fonts, which would make the look and alignment of text consistent on all OS-s. Though changing these font settings can wait for after the release. > > - 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. > > IIRC that was last touched in git.428e836. The installer for the jsmooth gui I downloaded from the jsmooth project at SF crashed when I was trying it, which does not inspire confidence in its stability. That commit was about izpack, but I found another where only the jsmooth jar got updated to latest version, not the config files for it in our build directory. I plan on trying the zip they also provide, to check all options in those config files for it. > > It'd be nice if you had answers for all my questions. > > Sorry to disappoint. Lots of this is stuff I have never worked on (or > barely understand what I did do, which would be anything in > build.xml), or was all in place before I joined the project, or is > windows related. NP, thank you. Another new problem I found is dialogs are not compatible with the classic UI mod. The outside is not using the changed background texture. I'd like to get this fixed before the release, but its not very important. Some panels would also need some changes to have them not draw another layer of background when they are contained inside another that already provides one, which is related, though that could also wait. > > You sure have backups of the complete SVN and bug/feature trackers? > > Not the SVN, I regard that as archival. 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. Greetings, wintertime ------------------------------------------------------------------------------ _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
