[sword-devel] BibleCS Installer: readme before executables

[L.Allan-pbio]

DM Smith wrote:
> The implementation is not a hybrid of C&D but more a variation on C as you 
> gave in code below.
>
> If it is clearer to swap the labels, I would be glad to do that.

Your call ... I don't really have a real preference ... maybe lean towards 
not changing the labels, and have the minor potential for an end-user being 
"mildly astonished" that the readme.txt shows up before the InstallManager, 
even though it is below on the FINISHPAGE.

> I've uploaded the changes to 
> http://www.crosswire.org/bibledesktop/biblecs/biblecs/installer.
> See SwordSetup.nsi and SwordFinish.nsh for the implementation.
> Please note, it is a snapshot that compiles, but might not be correct.
> I have not gotten to most of the problems that you have noted and may have 
> introduced a few more.

Something to consider ... the LcdPrototype .nsh files for CrossWire and 
Product !includes have the notion of identifying where the Files are coming 
from, in addition to !defines for the registry entries. I can see the 
advantage of having a "stage" directory ... this gives you a "snapshot" of 
the release. However, the previous SwordSetup.nsh files that I have looked 
at seems to have a "hybrid" of getting some Files from the "stage" 
directory, and some from the actual development CVS files from the actual 
sword folders. I would suggest one or the other, but not a hybrid.

My vote would be to maximize usage of a "stage" directory, which would have 
LICENSE, icu files, etc. I think there is a BIG advantage to having a 
"snap-shot" of exactly what went into the release ... but I write this as 
not that experienced with CVS and this may be counter to CVS preferred 
practice regarding milestones.

> For example, I am working on creating several headers and while they 
> compile, they are not done.
> Also I am moving to the HKCU/HKLM solution by calling SetShellContextVar 
> all in .onInit and un.onInit.
> I've also created a macro for the splash screen and am trying to 
> generalize it.

Personally, I don't like splash screens .... at all ... unless something 
else useful can be going on in the background. However, they certainly have 
some "sizzle" for end-users that conveys a professional caliber product ... 
which is very important for freeware where the perception can be that "you 
get what you pay for." I speculate that developers don't particularly 
comprehend the pervasive and justifiable skepticism that Windows end-users 
have for freeware and the risk of malware. About anything to convey 
professionalism is a good thing and justified.

I would suggest consideration of the LcdBible prototype practice of having 
!define's for TEST_VERSION and RELEASE_VERSION that effectively comment out 
the splash screen (and avoid use of lzma so that the much faster zlib is 
used ... and the ABORT-NOTIFY ... and perhaps leave off icu##.dll and 
InstallManager and assume already installed ... and bypass some Welcome and 
license pages that are just extra irrelevant steps during development)

> Part of this is a preparation for something that Troy requested.
> He would like to drop a directory named "windows" into the installer 
> directory and have whatever is in that image be installed.
> Of course there would be some expectations of the contents in that root 
> directory, e.g. license, readme.txt, splash.bmp, executables, ... so that 
> the pages that depend on those files work.

Don't really follow this ... would LICENSE and readme.txt be part of this? 
Aren't they cross-platform? What would be an example of some actual filea in 
this ... the .bmp(s)? Are .bmp's cross-platform ... if so, are they less 
preferred than other image file formats?

My impression is that you are the person responsible for the next JSword 
installer. You are probably already doing this, but try to maximize thinking 
in terms of how the BibleCS installer can be a template for the JSword 
installer to clone from. This is admittedly counter to getting a BibleCS 
installer done ASAP. This LcdBible developer has an acknowledged 
self-interest that they can be "siblings in a family of apps that play nice 
and share together."