* 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.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
