I was referring to the link I provided. I don't have enough experience or
accessible machines with earlier OSes. If our minimum target is Win98 then
I think that HKCU is a fine target.
Keep me posted on your findings and suggestions here.
Separate email.
I will be adding a page for choosing additional shortcuts:
Desktop shortcut
Quick Launch shortcut
(could do others such as adding links to IE to the project's home page,
to make the project's home page IE's home page, .... But I am not inclined
at this time.)
I am really surprised that MUI does not have built-in support for it. (At
least, I couldn't find it.)
NSIS has an incredible forum for getting questions answered. Tremendous
support.
http://forums.winamp.com/forumdisplay.php?s=cb2e4e96ee9947ecf5dd456c7c676ce7&forumid=65
And a mature wiki
http://nsis.sourceforge.net/Category:Code_Examples
I've been doing quite a bit of experimenting with "custom pages", and may be
starting to understand them.
* You've got an !include for WriteEnvStr.nsh, and a section for that, but
no Components page. Is that silently done then? Are you really intending
to write the SWORD_PATH environment variable?
Yes that is silent. I think it should always be set. But I could be
convinced otherwise.
(It is helpful to JSword which as a portable app, does not look at the
Windows' registry.)
I just heard about SWORD_PATH for the first time yesterday. What is it's
definition?
In JSword we have two notions of path. One is the set of directories that
contain mods.d and modules and the other is the one directory to which the
installer should write. For the latter, we allow one per install site
(e.g. stable, beta, local).
Does SWORD make this distinction?
Should we also back this with a registry key.
Should we allow the user to choose a location for the SWORD_PATH?
It looks like your earlier SwordSetup.nis sets the SWORD_HOME environment
variable rather than SWORD_PATH. Was this intended? On Win98, this re-writes
autoexec.bat and suggests a reboot.
I'm an advocate of setting (and using) SWORD_PATH, but my impression is that
Troy G. may not be so inclined ...
(Also, the uninstaller references swicu20.dll and icudt34.dll. Did you
intend icudt28l.dll ?)
Regarding the SWORD_PATH environment variable:
In the SWMgr::findConfig method, there is a sequence of "detection sniffing"
going on to find the "modules" subdirectory and associated .conf files. My
understanding is that this applies mostly if the "modules" subdirectory
isn't directly "under" where the executable sword.exe is running. The
current "resolution" is (with proposed changes interspersed):
+ * 1a. (proposed .... not current) [BaseCrossWireDir]/mods.conf
+ * 1b. (proposed .... not current) [BaseCrossWireDir]/resources/mods.conf
+ * 1c. (current) [BaseCrossWireDir]/SwordApiBasedApp/mods.conf
+ * 2a. (proposed .... not current) [BaseCrossWireDir]/mods.d
+ * 2b. (proposed .... not current) [BaseCrossWireDir]/resources/mods.d
+ * 2c. (current) [BaseCrossWireDir]/SwordApiBasedApp/mods.d
+ * 3. [SWORD_PATH environment variable]/mods.conf
+ * 4. [SWORD_PATH environment variable]/mods.d
+ * 5. [HOME environment variable]/mods.conf
+ * 6. [HOME environment variable]/mods.d
+ *
+ * Caveats: - I'm not familiar with Linux ... above assumes Windows
+ * - Not familiar with how "augPaths" works
+ */
A possible usage of SWORD_PATH may be to have a sword-api based app in a
subdirectory without any modules "under" its installation subdirectory. The
modules would be "found" with SWORD_PATH. This is more in line with a
"family of sword-api based apps" that share resources.
I'm only barely familiar with JSWORD .... is that your "home project"? What
does it use for an installer? The 2nd generation of the InVerse scripture
memorization freeware was in Java, but the installation was tough .... part
of why I changed to MFC.
* What is your preference on detecting and possibly over-writing a
BibleCS 1.5.6 installation? There is the statement:
InstallDirRegKey HKLM "${PRODUCT_REGKEY}" Path
which resolves to HKLM SOFTWARE\CrossWire\The SWORD Project
sword.exe 1.5.6 used:
HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\sword.exe"
"Path"
Sword 1.5.6's usage is correct, mine is a mistake.
* I would suggest using more meaningful section names than the Eclipse
generated sections
Section -Main SEC0000 ---> Section -Main SecWriteFiles
Section -post SEC0001 ---> Section -pose SecWriteRegistryEntries
Section un.Main UNSEC0000 ---> Section un.Main SecUninstallFiles
Section un.post UNSEC0001 ---> Section un.post
SecUninstallRegistryEntries
Good idea. I am still learning about sections and pages.
* The MUI_FINISHPAGE might have the text "Run InstallManager" rather than
"Run The SWORD Project"
* 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.
* 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.
* I'm curious about your thoughts/preferences about a "StarterKit" that
includes a Bible so InstallManager isn't requried to be able to commence
usage. As it happens now, this SwordSetup installer is "empty" without
using InstallManager.
I see having three installers:
API only.
This installs/upgrades the files that a dependent application uses. I
don't know what these are. So I need some guidance. (i.e. file list)
So an LCDBible installer would execute this installer if the API is not
present (as determined by registry keys).
BibleCS only. (This is what I am working on as this seems to be a good
starting point)
This would present the README (if user checked),
then the InstallMgr followed by sword.exe (if user checked to run the
app.)
BibleCS starter kit. (This should be an easy add as you have done the leg
work.)
This would allow the user to select from several modules (e.g. the ones
included with 1.5.6, but current).
Then present the README (if user checked)
then run sword.exe if checked.
I have read that a single installer script can build multiple installers.
So, hopefully, I can layer these on.
* 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.
How I do this depends upon whether I can get the check box state and
whether the checkboxes callbacks are run sequentially.
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.
----- Original Message ----- From: "DM Smith" <[EMAIL PROTECTED]>
To: "SWORD Developers' Collaboration Forum" <[email protected]>
Sent: Monday, February 06, 2006 3:33 PM
Subject: Re: [sword-devel] BibleCS Installer
L.Allan-pbio wrote:
From SwordSetup.nis
;--------------------------------
; Establish and remember the Start MenuGroup info
!define MUI_STARTMENUPAGE_DEFAULT_FOLDER "$[PRODUCT_TITLE}"
; Remember where it is
!define MUI_STARTMENUPAGE_REGISTRY_ROOT HKLM
!define MUI_STARTMENUPAGE_REGISTRY_KEY "${PRODUCT_REGKEY}"
!define MUI_STARTMENUPAGE_REGISTRY_VALUENAME StartMenuGroup
;--------------------------------
This may be a no-no .... HKLM should apparently not be used with
installations because it assumes the end-user doing the installation
has administrator privileges.
I thought about that, but according to the NSIS site that HKCU is not
available under Win9x and WinME.
See:
http://nsis.sourceforge.net/Add_uninstall_information_to_Add/Remove_Programs
If so and we go the HKCU route then we need to add in OS version
detection.
If Win9x then HKLM automatically.
Else, it should be a choice in the install to install for the current
user or for all users.
But if several users on the same machine install to the current user,
how would that work? I mean where would the program be installed? Where
would the modules be located?
In any "home" installation at least one person has administrator privs.
In a company setting, the user may not have admin privs and may even be
shut out from doing any installs even HKCU or changing/adding
environment variables.
I'm not sure that it is worth trying to install to HKCU. I think perhaps
we need to go for the lowest common denominator ;)
Ouch .... I hadn't been aware of this, and have always developed
installers that assumed the end-user had admin privilege. I'll do some
more research on this.
See:
http://www.microsoft.com/winlogo/software/windowsxp-sw.mspx item 3.3
http://www.microsoft.com/mspress/books/sampchap/6271.asp
Comment: "You're having trouble installing a program for a user with a
limited account"
nsis forum question:
http://forums.winamp.com/showthread.php?s=&threadid=237355
<http://forums.winamp.com/showthread.php?s=&threadid=237355>
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
