Talk:Choosing a SWORD program
For the front end links, we need to choose either links to homepages or links to wiki pages, not both. --Osk 06:27, 28 February 2009 (UTC)
I would recommend not listing that front ends can be localized. I don't think that actually matters to any users. What is important, and hence what we should list, is the existing list of UI localizations for each front end. (Ability to display RtoL text is a separate issue, independent of UI localization, so I think that's fine to keep.) --Osk 06:42, 28 February 2009 (UTC)
"Archiving" means what? Removal to another location? Compression? Consider whether this is a feature that is actually important to users in their process of making a decision between front ends--not just an attempt at one-upping. --Osk 01:45, 1 March 2009 (UTC)
What does "Complex Scripts" mean in this context? When people talk about complex scripts, they're not generally talking about basic things like Arabic shaping. They generally mean things like contextual shaping of Indic or rising baseline Arabic calligraphy. And this feature could have differing values for a single front end, depending on the platform. --Osk 02:03, 1 March 2009 (UTC)
- I think originally Peter meant support for Myanmar which BibleCS lacks. I take issue with the notation (with Uniscribe) because I *have* Uniscribe, and have told BibleCS to use a font that I *know* has the correct symbols, yet BibleCS can still not display the text. --mwtalbert
- So, should we change the category "Complex Scripts" to "BurJudson works"? I could release a module (assuming I could get permission, that is) that would universally fail because none of the existing front ends can support its writing system. Would we then mark all front ends as not supporting complex scripts?
- The notation about Uniscribe is more descriptive than a "yes" or "no", since the best possible result any front end can report is support of some complex scripts. Unless I'm simply mistaken (which is certainly possible) and BibleCS's RTF control doesn't actually use Uniscribe, the failure to correctly render BurJudson is simply indicative of Uniscribe not completely supporting that script yet. (I will investigate whether I'm wrong about Uniscribe.) --Osk 20:59, 1 March 2009 (UTC)
Image GenBook support
Users do not know what GenBook means. Are images really unsupported in any kind of module type? --Osk 02:03, 1 March 2009 (UTC)
- There is a bug in Bible Desktop, that has been fixed in SVN, that did not properly determine the proper display a Dictionary (LD) with images that is also marked Category=Maps. BD/JSword support all image types that Java can render. I don't know what that is, but at least it includes all the types that we would use in a module.--Dmsmith 14:01, 1 March 2009 (UTC)
Image Formats / other Image Module support
These are not things that an end-user cares about. --Osk 02:03, 1 March 2009 (UTC)
- I agree. I think this can be generalized to a bigger issue. Karl has a wonderful repository of non-official, very useful modules. These may show problems in end-user applications. For example, if his map modules have png images, then there is some front-end that does not support it. The user cares about available modules working or not working.
- I already mentioned the Bible Desktop bug regarding LD image modules marked as Maps. While I routinely test JSword/BD against all CrossWire modules, I don't against Karl's repository. Given it's visibility and value, I think I should.
- The bigger question is how do we note short-comings/bugs in a particular application? I don't think this is the appropriate venue. (Though I don't mind JSword being called out as lagging SWORD.)--Dmsmith 14:10, 1 March 2009 (UTC)
- I have to run to church right now, but as soon as I get a chance, I'm going to nuke the whole Images category down to a single, uninformative "Supports Images" column, universally marked with "yes". --Osk 18:57, 1 March 2009 (UTC)
What are study notes in the tagging section? Benpmorgan 09:00, 1 March 2009 (UTC)
BibleCS is not properly portable. For once I'm not even applying the stringent PortableApps.com "stealth" requirements. It depends on some libraries (which they are escapes me) and controls which may not be installed on the local user's machine. Also, it leaves stuff all over the place in the registry, and registers itself and so on in a way which leaves orphaned entries in the registry in a most horrible way. What I really complain about though is the fact that on some computers, it won't even just be "Just Works™". For reference on some issues, see this thread on PortableApps.com. Chris Morgan 10:53, 1 March 2009 (UTC)
- I have just read the thread and I don't think it applies. BibleCS is properly portable wrt to the registry, but it takes some work. First, one has to install it to the default location, which uses the registry. Then one copies c:\Program Files\CrossWire\The SWORD Project to a thumb drive. Then it is un-installed from the local machine. This is a one time operation. Second, the user has to use the built-in module installer and not the windows modules downloaded from CrossWire in Windows format. The latter uses the registry. Is it this specific path that prevents the "Just Works". It would be simple enough to zip the contents of that directory and make it available as a portable download. Would that qualify as "Just Works"?
- As to the library problem, if you can recall them that would be great. This it the first I have heard of this.--Dmsmith 14:28, 1 March 2009 (UTC)
- You can't recall which libraries it requires because it doesn't. Everything needed by BibleCS is contained within its directory. It writes a few registry entries, but does not need them for its own functioning (only for private protocol calls). And those registry entries really could be deleted upon exit, if desired. So if you move BibleCS around to computers other than that to which it was installed, it will work perfectly fine. --Osk 18:53, 1 March 2009 (UTC)