[sword-devel] New website - installation instructions
Troy A. Griffitts
scribe at crosswire.org
Fri Dec 19 12:33:31 MST 2008
OK, so would this be a fair assessment of the requests on the table?
To the C++ Engine add searching in:
$HOME/Library/Application Support/sword
$APPDATA/sword
$ALLUSERSPROFILE/sword
Change the C++ Engine to 'augment' the installed module list with any
works found on any path, instead of the precedence implemented currently.
Add the concept of an 'install location' to be the 'first' found
writable location.
Make both JSword and SWORD operate exactly the same for module set lookups.
-Troy.
DM Smith wrote:
>
> On Dec 19, 2008, at 3:08 AM, Troy A. Griffitts wrote:
>
>> Just a few comments.
>>
>
> ... snip..
>
>> One of them is probably what BibleCS does right now-- putting modules
>> in ./ This does not allow another application to find the installed
>> module set. I THOUGHT (DM can comment on this) that we set SWORD_PATH
>> env variable on install. If this is the case, then all SWORD apps
>> will find current modules.
>
> The BibleCS installer sets SWORD_PATH. I think I said that this is a per
> user setting. I got this backward. It should be an all user setting. But
> I don't remember.
>
> The problem is that BibleCS looks first at ./sword.conf and ./mods.d and
> because it's notion of . (the install directory) has mods.d (I forget if
> it has sword.conf) it will never look for SWORD_PATH set by some other
> program.
>
>
>>
>>
>> IF A USER CAN INSTALL OUR SOFTWARE TO PROGRAM FILE, then they should
>> be able to WRITE to program files to install modules. Yes?
>
> The ball game is different under Vista. I don't have Vista. I don't know
> of a Vista machine that I can use for testing. So, anything I say is
> hearsay.
>
> I heard that Vista has a two-level administrative permission scheme.
> That is an administrator may be required to authorize an install.
>
> If this is the case, then the permission to install is not the same as
> the permission to write.
>
> The other problem from Win XP (perhaps ME) onward is that if one user
> has permission to install, that doesn't mean that another has permission
> to write. This is the "shared module" problem.
>
>>
>>
>> Regarding private modules, If GS or another app wants to include
>> private modules, then they can call AugmentPath on SWMgr or else we
>> can agree to a common area and place that in our sword.conf
>> configuration file in our ./ app directory.
>>
>> Just a comment: Vista still sucks and no business I have ever worked
>> for to this day has installed it on company computers. They all take
>> advantage of Microsoft's free 'Downgrade' to XP. Not that this means
>> much because our users are mostly home users running Vista, XP, or
>> earlier.
>>
>> So, to sum up. I think we should:
>>
>> Not supply app-specific config data to SWMgr, but let SWMgr default
>> through it's normal discovery process. This will let all SWORD apps
>> work the same.
>
> I agree that it should not be app specific. But I do think it needs to
> be OS friendly.
>
>>
>>
>> Be sure JSword follows the same rules as SWORD C++
>
> Sort of. I outlined the differences in another reply. If BibleCS is
> installed first, it will find it's module repository.
>
>
>>
>>
>> Talk about and agree where we think modules should live on any number
>> of versions of windows.
>>
>> Then choose the appropriate discovery configuration options to find
>> modules in these places.
>>
>> If we agree on a scheme which we discover we do need to augment the
>> engine to support, then we can do this, but I think we will find a way
>> to configure things using the existing mechanisms (SWORD_PATH,
>> ./sword.conf, ../library/ whatever).
>>
>> And I STILL think Windows sucks and would personally throw my vote in
>> for NOT doing things the 'Windows' way, which will inevitably change
>> next release.
>>
>> I like putting modules in a subfolder with our apps so we can move
>> them around, e.g.:
>>
>> C:\Program Files\CrossWire\library\
>> C:\Program Files\CrossWire\The SWORD Project for Windows\
>> C:\Program Files\CrossWire\BibleDesktop\
>
> This is what you and I agreed on, but the BibleCS installer and the
> BibleDesktop installer do not do this.
>
> Others are saying that under Vista this is problematic.
>
>>
>>
>> Or just leaving them under:
>> C:\Program Files\CrossWire\The SWORD Project for Windows\
>> where they are already installed for Windows users because of BibleCS
>> (and hopefully we are setting SWORD_PATH) The above name doesn't sound
>> too much like a frontend specific name because of how uncreative we
>> were with BibleCS' public name.
>
> This would work if SWORD_PATH is looked for first. Otherwise, BibleCS is
> not a good team player.
>
>>
>>
>> Other comments:
>> When was the last time a user looked in there HOME directory on
>> Windows, had any clue what any of the files in there were for or cared
>> if any of them started with .?
>>
>> [root at localhost Scribe]# pwd
>> /windows/c/Documents and Settings/Scribe
>> [root at localhost Scribe]# ls -latd .??*
>> drwx------ 1 root root 8192 2008-11-13 00:24 .gimp-2.4
>> -rwx------ 2 root root 2086 2008-11-13 00:23 .recently-used.xbel
>> drwx------ 1 root root 4096 2008-05-22 15:31 .borland
>> drwx------ 1 root root 0 2008-05-22 15:31 .rwpgxhapeide
>> -rwx------ 2 root root 0 2007-09-09 16:27 .gtk-bookmarks
>> drwx------ 1 root root 0 2007-09-03 22:47 .cream
>> drwx------ 1 root root 0 2007-02-24 18:55 .DownloadManager
>> drwx------ 1 root root 0 2006-12-04 12:56 .flashcards
>> drwx------ 1 root root 0 2006-06-01 03:15 .dbpilot
>> drwx------ 1 root root 0 2006-06-01 03:12 .connections
>> -rwx------ 2 root root 2984 2006-06-01 03:12 .1149156731656.slip
>> -rwx------ 2 root root 3249 2006-04-29 13:39 .1146343195000.slip
>> drwx------ 1 root root 0 2005-09-15 20:43 .thumbnails
>> -rwx------ 2 root root 322715 2005-09-15 20:41 .fonts.cache-1
>>
>> :)
>>
>> -Troy.
>>
>>
>>
>> Matthew Talbert wrote:
>>>> There's nothing wrong with a "." at the beginning of a file or
>>>> variable name. It simply hides the folder from regular user view,
>>>> which is how it should be. The data in there is not intended for
>>>> direct user interactions. If people want to see hidden folders/files,
>>>> they can enable it.
>>> No, on windows it doesn't hide the folder, which is the problem.
>>>> XP is still a recent version of the NT chain. It's still supported
>>>> and available on certain machines, and shares a significant amount of
>>>> user popularity - that's my meaning of recent. I don't know when in
>>>> the NT family the concept was introduced of the User directory, but I
>>>> know it's been in since at least XP. Not that it much matters,
>>>> because bending over backwards to support anything pre-XP is most of
>>>> the SWORD applications is going to be beyond tedious for minimal gain.
>>> 8 years old is recent?
>>>> From how I understood Troy, it was merely for the installation of
>>>> modules - not the creation of them - that he was advocating putting
>>>> them in Program Files. Per-user data should probably still be kept in
>>>> some sort of per-user location. But installing modules to be shared
>>>> across the front ends and users should be done in a more global place.
>>>> Perhaps the path \Users\Public\Sword should be used for the regularly
>>>> installed modules, and set to SWORD_PATH, then a per-user folder in
>>>> %HOME%\AppData\Sword or %HOME%\.sword
>>> You are basically saying what GS intends to do, but that is certainly
>>> not how I understood Troy.
>>> (as for not having "." at the
>>>> beginning of folders, I currently have .dvdcss, .housecall6.6, .kde
>>>> and .VirtualBox in my home directory -- it's definitely not unheard
>>>> of).
>>> I know, but it's like creating a visually unappealing program for a
>>> Mac user. Littering the user's home directory with .folders is not the
>>> most user friendly thing that could be done.
>>>> I don't remember if XP supports the \Users\Public, but I think it
>>>> does. I know that World of Warcraft, in a recent patch, decided that
>>>> it should recommend that users move the whole game folder to
>>>> \Users\Public\Games\World of Warcraft instead of \Program Files\World
>>>> of Warcraft. After all, that's what the public is for -- shared data
>>>> that users are allowed to read/write to. What to do on Windows
>>>> systems that are pre-user, I have no idea.
>>> XP doesn't have \Users\Public. It does have All Users\Documents, which
>>> might be a more correct place to put shared things, but I'm not sure.
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel
mailing list