From: Vampire <Vampire@jEdit.org> - 2010-12-14 23:16:57
|
Kazutoshi Satoda schrieb: > Vampire wrote: >> I'll see what I can do here as soon as I can. >> For some of the things I just wanted to do it the right way and I wanted >> to complete this thing as fast as possible to not delay the release any >> further. > > Since there are issues shown in front of my eyes, I'm no longer in > rush. I believe all admins are in same feelings. Obviously not as Eric and Alan show with their mails. Could you please answer to Alans mail as of 6,5 hours ago about delaying the release any further or not and state your opinion about the situation there? Btw. some quick thaughts about the parts of my change you mentioned are questionable for 4.4: - Made the Windows launcher buildable on any system This is more or less part of the "- Fixed the build.xml which was for the Windows installer only working if completely run on Windows, making "ant dist-win" on another system and then using "ant dist-win-finish" was broken" change which you agreed for 4.4 - Made the Windows installer buildable completely via wine on on non-Windows systems This is just a build-file change and makes creating the release a little bit easier for me as I'm creating the releases on Ubuntu now. So I think this could go into 4.4. - Made our documentation build on FOP 0.93+, 0.20.5 is no longer supported by our files To be honest, I see it as bug that our documentation still was tailored to 0.20.5 as this is long obsolete since the rewrite became stable in version 0.93 almost 4 years ago. And it was essentially a rather small change that was necessary. - Included the Windows launcher in the Java installer As far as I have seen the Java installer did not even provide the BAT launcher. So if someone used the Java installer he was not able to assign file types with jEdit which I saw as a biiig drawback. I just didn't really recognize this before as I usually use the Windows installer. I see this is a major drawback if it is not present. >> - Made the Windows installer correctly show special characters like >> german umlauts > I want to reject this. This doesn't work on some localized Windows > environment. The following revision had avoided the problem, and > reverted now. What do you mean by reverted now? If there was a problem with some localized Windows, then the commit you mentioned didn't avoid the problem, as there were still special characters like german umlauts in the message files and there were also special characters in the ISS file, not only the copyright symbol but also german umlauts. The problem was that using the Ant <copy> task with a <filterset> subtask reads and writes the files in the default system encoding if no explicit one is specified. We use that constellation for our package-files amongst which the ISS file is. This means, building the installer on windows reads and writes the file in ISO-8895-1, building the installer on linux reads and writes the file in UTF-8. With those special characters inside, this is of course not good as you may see. Even fixing this by attribute to reading and writing in UTF-8 did not help, as Inno Setup, despite its documentation, doesn't cope well with UTF-8 encoded file, maybe it only works with BOM and not without. Because of that I configured the copy task to read in UTF-8 and write out ISO-8895-1 which worked fine for me here. Do you have access to such a localized Windows environment where the problem you tried to workaround instead to fix exists and could test whether my measures work? >> - Removed the BAT launcher in the Windows installer in favor of the >> EXE launcher > I thought this too, but didn't. Because I thought the removal can > break some written call to jedit.bat. Actually the installer doesn't remove the existing BAT launcher. For new installations and after removal, only the EXE launcher is put in place. But if the BAT launcher was present before, it is not removed. I thought about adding this to the ISS, but then had the same thoughts as you have about written calls to jedit.bat, even if I doubt someone has done this. But who knows. So for new installations I think providing only the EXE launcher is the better choice. > The option "JdkPreference" is changed from "preferJre" to "preferJdk". > I disagree on this change. > > http://jedit.svn.sourceforge.net/jedit/?view=rev&rev=19118 > http://sourceforge.net/support/tracker.php?aid=3134149 > I still think "preferJre" is better to match old behavior. I don't think so. The old behaviour always was to prefer the JDK over the JRE and we always encouraged users to use a JDK to run jEdit in favor of a JRE. The main reason for this is the availability of tools.jar which is needed by some plugins. Don't ask me which, I don't remember currently. You can see this order in the current ISS file on trunk. It first searches for a JDK, and then if none was found or if it was too old, it searches for a JRE that is new enough. Then, later on, someone introduced a search step up-front for a javaw.exe in the system directory. This made sense as a work-around around the problem if someone upgrades his java installation as the paths were hard-coded in the registry and the BAT launcher after the installer was finished and one would have to re-run the jEdit installer to adapt to the new Java version which was not necessary if the javaw.exe was updated by the Java installation. This unfortunately made a behaviour of "preferJre" while we always wanted a behaviour of "preferJdk", but work-arounds often have a drawback. Now with the EXE launcher we are in the happy position to undo the drawback of the work-around and thus I think that "preferJdk" is the right choice here, what do you think? Regards Vampire |