Just a few comments.
I'm not telling people to do things the WRONG way.
I am pointing out how the SWORD engine looks for it's configuration.
Has anyone complaingin actually read the doc I pointed to? This complex
method of looking for configuration data allow for ANY imaginable
configuration which has been suggested. There is no need to augment the
engine to handle anything. What we need to do is agree on how Windows
apps should play together and do thing accordingly. If we all use the
default SWMgr() behaviour without specifying our own non-standard path
to look to for modules, then all of our apps will play nicely together.
That's not the issue. The same SWORD engine compiled into all of our
apps will find modules the same way. There are a few things we need to
think about avoiding.
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.
IF A USER CAN INSTALL OUR SOFTWARE TO PROGRAM FILE, then they should be
able to WRITE to program files to install modules. Yes?
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.
Be sure JSword follows the same rules as SWORD C++
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\
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.
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 .?
[r...@localhost Scribe]# pwd
/windows/c/Documents and Settings/Scribe
[r...@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@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
