Difference between revisions of "Talk:Choosing a SWORD program"

Revision as of 03:16, 2 March 2009

Project Links

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)

Localization

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)

The original intention of each entry in the table was/is that it gets removed if a feature is present in all frontends. This one means little to end users , but it means something to translators and developers. If we can find out whether SwordBible can get translated easily then all are localisable and the feature should be listed above the table

Archiving

"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)

Osk - if you mistook this table as one-upmanship then you are badly mistaken. I tried to unravel the narrative everyone seems to give about their frontend. Archiving is GS tem for keeping modules out of sight but available. It does what it says on the tin. BT has (I think) a different solution to the same concern. The tables are quite obviously increasingly not anymore for first time users, but that is quite irrelevant. We can always finally extract the core points for a message to users, but there are other uses for these tables possible too - for developers, for translators - where to concentrate effort etc refdoc:talk

Complex Scripts

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

This is a bad misunderstanding or misquote. I never singled out BibleCS in this matter. All frontends failed BurJudson, some worse some less bad. The level of support can clearly not always get answered with simply yes/no. But as such it is an important matter - as some frontends are constitutionally incapable of rendereing such scripts and others require additional work (which is fine if it works) refdoc:talk 23:04, 1 March 2009 (UTC)

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 was this, Osk? I have restored the section and would appreciate if it stays up. This section has meaning and is reflected in existing modules refdoc:talk

To be clear this is not about bugs but about frontend limitations - so once it is clear that all frontends can actually deal with all module types then the point simply gets deleted and amalgamated in the "all frontends do xyz" list. refdoc:talk

All front ends support basically the same set of features, with respect to images, in either their current release or in SVN. And these are not end-user concerns, they are developer concerns. Users don't know which format module images use or which kind of module they will appear in, they simply expect content they download to work. So this whole section is completely unnecessary to users. Front end developers don't need it either, since all limitations have already been worked around (namely, the SVN versions of all front ends should now support JPEG & PNG images in all module types). (I don't consider other formats necessary, so we won't ever release content that uses other image formats.) The particulars of which versions of various front ends support which formats & which module types may be useful to content developers, but I can advise them of that during the submission process, and this need not be included as part of a feature matrix aimed at end users. --Osk 03:16, 2 March 2009 (UTC)

Study Notes

What are study notes in the tagging section? Benpmorgan 09:00, 1 March 2009 (UTC)

Study notes are simply a text editor type note taking facility which then can get exported - e.g. for sermon preparation. This could have gone just as well to other, or where ever, but in the end it is often the final result of a search and bookmarking exercise that you go and write something up which tyou then print and take somewhere else. refdoc:talk 22:52, 1 March 2009 (UTC)

BibleCS Portability

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)