[sword-devel] BibleCS Installer

[L.Allan-pbio]

>> * I would suggest consideration of having the "Family !define" statements 
>> and perhaps some of the "Product !define" statements be in separate .nsh 
>> include files ... a'la:
>> !include "CrosswireFamilyDefines.nsh"
>> !include "LcdProjectDefines.nsh"

> This is a good idea.

The idea would be that many/most of the statements in the installer wouldn't 
need to be changed much ... they would be "cloned" for a new "sibling" of 
the "sword api family of apps". (but easier said than done <g>)

My impression is that the "family" within the Windows world includes 
sword.exe (a.k.a. The SWORD Project aka biblecs), LcdBible, BibleStudy, 
JSword, and perhaps others. They use the sword-api to access shared modules 
(like Bibles, commentaries, etc.). My further impression is that the 
publishers have permitted their copyrighted intellectual property to be 
accessed this way (such as MKJV and LITV from Sovereign Grace Publications, 
ALT from "Darkness to Light", etc.)

>> * Do you have intentions of eventually detecting a prior installation of 
>> BibleStudy, LcdBible, sword.exe 1.5.6 or earlier, JSword? ... the issue 
>> is to avoid redundant installation of resources (KJV, WEB, etc.)

> Eventually.
> (Right now JSword is not nice in this regard: it maintains its own 
> download area. I'd be glad to change this if we can get a solid way to 
> discover the location.)
> I think that the mods.d and modules directory should be retained across 
> installs as a shared resource.
> During the uninstall the user should be asked whether to remove the 
> modules or not.
>
> Right now the uninstaller wacks everything. It is what Troy requested, but 
> I may have misunderstood.

My understanding is that the InstallManager is ideally/theoretically 
supposed to be used to uninstall the actual modules. With several "sibling 
apps" installed, there is a LOT that can go wrong during the uninstallation. 
Perhaps "a poor craftsman blames his tools", but I haven't found the 
InstallManager to be particularly intuitive and obvious how to use. (I 
started putting together an animated slideshow to illustrate how to use it 
...)

Also, SWORD_PATH may be useful for developers testing what happens with 
various combinations of modules installed.

> I have read that a single installer script can build multiple installers. 
> So, hopefully, I can layer these on.

I'm aware of using Sections, and have looked at InstTypes (which provides 
for different categories of installers .... which may be what you are 
thinking of) .... however, the installer itself would have the entire 
contents within it, so would be large. I think that there can only be one 
"OutFile" statement.

I've used !define statements with other freeware apps to generate nsis setup 
installers for just the .exe update (small), the "StarterKit" (medium size), 
and a MaxSetup (relatively large)

!define INSTALL_JUST_EXE_VERSION
; !define INSTALL_FULL_VERSION
; !define INSTALL_MAX_VERSION

(this is similar to the LCD_TEST_VERSION and LCD_RELEASE_VERSION !define's 
I've using in the prototypes .... mainly to speed development by using zlib 
instead of lzma, and avoid the large icu and InstallManager files that take 
a looooong time to compress)

>> * It is possible to have the the MUI_FINISHPAGE reference a function, 
>> which can have a sequence of .exe's invoked:
>>
>>  !define MUI_FINISHPAGE_RUN
>>  !define MUI_FINISHPAGE_RUN_FUNCTION OnFinishPageRun
>> ; more statements here
>> ;--------------------------------
>> /*
>> * Function: OnFinishPageRun
>> * Notes: -
>> */
>> Function OnFinishPageRun
>> SetOutPath $INSTDIR
>> ExecWait 'InstallManager.exe'
>> Exec 'sword.exe'
>> FunctionEnd

> The situation is a little more complicated than this. The MUI_FINISHPAGE 
> can be defined to allow viewing the README and running the application. 
> The user can select one, the other or both of these.

> The current behavior is to do these with out waiting and it does the 
> application first and then the readme.
>
> We need for the user to see the readme first, if requested and then the 
> application, if requested.


My experience are that both happen pretty much at the same time .... they 
aren't sequenced. It seems ok to me to have the readme.txt showing at the 
same time as the InstallManager, because (I believe) the readme.txt is about 
using the InstallManager.

You can use "ExecWait" on the InstallManager and then Exec on the sword.exe 
to sequence them .... to make it more likely that the InstallManager has 
been used to acquire a module before running sword.exe

> How I do this depends upon whether I can get the check box state and 
> whether the checkboxes callbacks are run sequentially.

This may be better done with "Visible Sections" and the Components page. You 
can use SectionGetFlags to see which options of the Components page were 
checked.

> If so I would register the same function to both the README and to the 
> application check boxes.
>
> The function would be something like:
> done = false
> function doit
>    if not done then
>       done = true;
>       if readme checked then
>          if run program checked then
>              execwait readme
>          else
>              exec readme
>          endif
>       endif
>       if run program checked then
>          execwait installmgr
>          exec sword
>       endif
> endfunc
>
> I am trying to keep from using string literals as much as possible and 
> using default MUI behaviors so that we can ultimately provide an installer 
> in the user's own language. The MUI has been internationalized into many 
> languages already.

Mea culpa ... I've tended to ignore internationalization issues.