[sword-devel] BibleCS Installer
dmsmith555 at yahoo.com
Wed Mar 8 06:18:24 MST 2006
Then it is ready. I'll zip it up and put it on the server tonight.
Troy A. Griffitts wrote:
> Hey guys. Excited about all the ideas moving forward with multiple
> windows installs, but please remember that THIS release is only
> intented to have the identical functionality as the current
> InstallShield installer, just so we can get an update out for the
> software. After that, I'm perfectly happy to entertain ideas about
> supporting multiple sword clients on a windows computer. I'm not
> trying to squelch creativity here. I really want to move forward with
> things, but we need to have milestones-- and we have a very immediate
> need. I agree with DM that we need to get this out sooner and worry
> about new functionality after.
> The current InstallShield uninstaller calls installmgr with a
> command-line option to remove all modules. Lynn, I understand this
> may not be what you want, but the switch to NSIS-- and thus an open
> installer which allows for future enhancement-- has to be TOWARD what
> you want. Please understand the need I'm trying to meet. It is
> nothing personal.
> L.Allan-pbio wrote:
>> Thanks for the update. Hope you don't mind the "cage rattling".
>> My impression is that the uninstallers for the front-end apps can and
>> should ignore removal of modules. As the military phrase goes, "that
>> is above my pay grade." <b>
>> The intention may be for the InstallManager to be responsible for
>> removal of most (all?) of the installed modules. Troy G would be the
>> one to check with on the specifics, but I think that the uninstallers
>> for the actual apps can pretty much ignore this complicated task.
>> There is lots that can go wrong with removing modules.
>> Perhaps it is sufficient for the application uninstallers to have a
>> checkbox on the "components" page (or the Finish page?) whether to
>> "launch" the InstallManager? The functionality of the application's
>> uninstaller would be otherwise limited to removal of its specific
>> executable(s), help files, .conf files, registry entries, environment
>> variables, icons, StartMenu entries, .ini files, jar files, etc. but
>> NOT the modules.
>> Unless it involves a pda, today's huge hard drives make it a
>> relatively lower priority to "clean up" everything during an
>> uninstall. My experience is that the fussy reviewers at
>> CNet/Download.com and TuCows pay attention to the thoroughness of the
>> uninstaller, but most end-users may not care if some resources get
>> left installed if they uninstall the app.
>> It would still be possible to do a thorough uninstall and "blow away"
>> every file, module, registry entry, etc, but the default "flow" of
>> the uninstaller for a specific front-end would leave modules and some
>> CrossWire "family" registry entries. There should be enough "bread
>> crumbs" left for a subsequent installation to be able to find a
>> "sane" place to install to facilitate module sharing.
>> IMHO, I think the difficulty of the uninstaller trying to figure out
>> all the combinations and permutations, and then making the choices
>> clear/unambiguous to the end-user about what they can and/or could
>> and/or should do are not worth the effort, and unlikely to be
>> Here is a scenario: a person has been using BibleCS sword.exe and
>> decides to try LcdBible and BibleStudy and BibleDesktop. The modules
>> are "sort of" shared, except some apps find the shared resources
>> within the directory structure (i.e. in the same directory as BibleCS
>> sword.exe which is how SWMgr::findConfig works now), some use
>> SWORD_PATH, and some have redundant resources (mods.d and modules in
>> their install directory and KJV has been installed multiple times,
>> for example).
>> I would advise against the uninstaller trying to figure out this
>> "hodge podge" out and attempt to "do the right thing". It seems too
>> likely that some modules will get unintentionally deleted which
>> interferes with the operation of other apps.
>> To me, the problem is that end-users with multiple CrossWire
>> front-end apps will intend to install a module, and be confused and
>> frustrated when some front-ends can "see" the module, and some can't.
>> Perhaps it would be appropriate to have a separate, simple program
>> that "sniffed around" the registry and certain default locations to
>> detect redundant modules, such as:
>> C:\Program Files\CrossWire\The SWORD Project\mod.d
>> C:\Program Files\CrossWire\LcdBible\mod.d
>> C:\Program Files\CrossWire\BibleDesktop\mods.d
>> C:\Program Files\CrossWire\mods.d
>> C:\Program Files\CrossWire\resources\mods.d
>> and then brought redundancies to the attention of the end-user. Some
>> redundancies would be intended, especially for developers. Such a
>> capability could perhaps be part of the InstallManager (the "test"
>> version of the LcdBible "StarterKit" installer used a very small
>> "proxy" for the InstallManager to do some of the above and could
>> probably be enhanced easily. This proxy was mostly to be a small
>> replacement for the large InstallManager.exe and sword.exe which made
>> the compression for the nsis installer be slow.)
>> My 2¢ worth
>> ----- Original Message ----- From: "DM Smith" <dmsmith555 at yahoo.com>
>> To: "SWORD Developers' Collaboration Forum" <sword-devel at crosswire.org>
>> Sent: Monday, March 06, 2006 8:24 AM
>> Subject: Re: [sword-devel] BibleCS Installer
>>> I just have one aspect left: On uninstall, don't wack installed
>>> modules if there is another registered "CrossWire" application.
>>> While this doesn't do everything on your wish list, I think it goes
>>> a long way toward it.
>>> For the last few weekends, I thought I'd get it done, but something
>>> always came up. Maybe, I can get it done tonight.
>>> Yes, you have noticed that I have spread myself a bit thin. In spare
>>> cycles I am working on cleaning up the KJV2003. Almost ready to
>>> check it in and make it available for edits.
>>> In His Service,
>>> L.Allan-pbio wrote:
>>>> Just thought I'd check what the status of the BibleCS installer
>>>> was. There was a big flurry of posts in early Feb, but I was
>>>> wondering if I missed the actual "release candidate". The last SVN
>>>> entry is from September.
>>>> Not meaning to be impatient, as I observe with gratitude (and awe)
>>>> the large number of different aspects of The CrossWire Bible
>>>> Society that you are working on. "Well done, good and faithful (and
>>>> profitable) servant." I would like to release an update of LcdBible
>>>> with compatible installer, and hesitate to proceed until a number
>>>> of pending issues and questions related to the BibleCS installer
>>>> are resolved.
>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>> Instructions to unsubscribe/change your settings at above page
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> Instructions to unsubscribe/change your settings at above page
>> sword-devel mailing list: sword-devel at crosswire.org
>> Instructions to unsubscribe/change your settings at above page
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel