On Thu, Sep 3, 2009 at 2:29 PM, Jonathan Marsden<jmars...@fastmail.fm> wrote: > Matthew Talbert wrote: > >> Note that setting SWORD_PATH is *not* the correct way to install into >> ~/.sword (there isn't a correct way with installmgr, I guess). SWORD_PATH >> does more things than just that, for instance, locales are >> loaded from SWORD_PATH/locales.d, ... > > I don't think installmgr is fully localized anyway :) I could just do > without installmgr (use wget to grab the KJV.zip file and unzip -qod > ~/.sword/ KJV.zip to install it), for this particular test, but ... surely > this is exactly the kind of task that installmgr is supposed to do for the > user, manage installing modules :) > > Also I have a similar script installmod.sh that takes a module name as a > parameter, so I can do installmod.sh WHNU and get the desired result. I > could rework that to just use wget and unzip too, I suppose. It just seems > a bit silly, when installmgr exists for this very purpose. > >> For Xiphos, we support installing into ~/.sword if DataPath isn't >> writable. We do this by checking it ourselves, ... > > OK. IMO it would have been preferable to get a patch into the libraries, > rather than work around this in just one front end application. That way, > your work and your testing benefits all SWORD apps, not just the one you are > working on (assuming your patch is accepted, of course!).
Maybe, but there are reasons that those applications which strive to be cross-platform do a lot of those things themselves. In order to support paths with non-ASCII characters, each OS seems to have a different proper way of doing this. At least on Win32 the only method I'm aware of is through calls specifically to the Windows API. Since SWORD tries to rely on as few external libraries as possible, it would need to have lots of #ifdef segments. A front-end like Xiphos can get away with a single call to the GTK/GLib libraries which handle those OS-specific calls for them (and BT could use the Qt classes, etc). My understanding is that the InstallMgr library class usually needs to be extended anyway by most of the applications, so adding the extra calls at the application level can tackle: (a) non-ASCII usernames, (b) path read/write permissions checks, (c) transport peculiarities like proxies, NAT, etc all in one pass, with the support of whatever external libraries the application is built on (GLib, Qt, XUL, python) doing the cross-platform lifting instead of trying to figure out every OS's requirements at the library level. --Greg > >> Secondly, it would be really nice to have a method to install to a certain >> directory ... > > Maybe, although I suspect that if the library did a better job of picking > the "right" place to install new modules to in the first place, by > distinguishing between readable data paths (for locales, or for finding > existing modules, etc.) and writeable ones (for installing, updating and > deleting modules), then manually specifying an install path would probably > not be necessary. > > Jonathan > > _______________________________________________ > 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
