[sword-devel] BibleCS Installer: readme before executables
paraclete at bibleinverse.org
Fri Feb 10 10:03:24 MST 2006
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
> 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."
More information about the sword-devel