Talk:Frontends:FeatureList

I've taken some comments out of the main page and moved them into this discussion page. Benpmorgan 08:08, 30 May 2008 (MDT)

Usability:

These kind of statements are so bogus that they actually mean nothing. All software should be easy to use and bugfree. Eelik 05:34, 25 May 2008 (MDT)

It is true all software should be easy to use and bugfree. However, most aren't. I put this on the list as they require special attention. Benpmorgan 08:08, 30 May 2008 (MDT)

Other

Any frontend using the Sword library MUST be GPL. Eelik 05:36, 25 May 2008 (MDT)

Only GPL v2 compatible. Jmmorgan 05:55, 30 May 2008 (MDT)

This is not true. I can use any GPL compatible license (or even public domain). It's also possible to use a sockets to communicate and not use an open source license at all Benpmorgan 08:08, 30 May 2008 (MDT)

I don't know why this would be confusing, but Sword is GPLv2 licensed. GPL is viral. All derivatives of GPL software must obligatorily have the identical license. (GPLv2 software must be GPLv2. GPLv3 software must be GPLv3. "GPLv2 or later" software must be GPLv2, GPLv3, or GPLv2 or later, or GPLv3 or later--depending on which license you select. But Sword is GPLv2 only (not later).) All frontends, utilities, etc.--anything that links to the library--are derivative works and therefore must be GPLv2 (or would be in violation of CrossWire's, the FSF's, and others' copyrights). It is not acceptable or legal to use other "GPL compatible licenses" or release Sword-derivatives into the public domain. "GPL compatible" refers to software that may be legally incorporated INTO GPL software. BSD & MIT are GPL compatible licenses, which is why we can use the ICU in Sword. LGPL is GPL compatible, which is why we can use CLucene. But it would not be legal for a piece of BSD, MIT, LGPL, or public domain software to incorporate Sword. Sockets are an independent matter and software based on them wouldn't be a frontend in the normal sense. If someone DID create a Sword sockets utility--that would obligatorily be under GPLv2. And if someone were to create a non-GPL UI that made use of sockets to exploit Sword then we would likely license all content such that it could not be used in non-GPL software or non-CrossWire software (making such UIs fairly useless unless you're willing to break the law). Osk 12:03, 30 May 2008 (MDT)

Small note, as Jmmorgan today made an edit to this page implying that GPL-compatible licenses were acceptable. This is entirely incorrect. He has communicated with FSF's licensing folks for a clarification and they confirmed that while a GPL-compatible licenses would be acceptable if Sword were GPL3, that is not the case with GPL2. Consulting a pre-GPL3 version of the GPL FAQ should make this abundantly clear (or, you know, reading and understanding the license itself). Don't modify this section of this page (or any other) to this effect. Don't misunderstand that all front ends (and other software derivative of Sword) must be GPL2 licensed. --Osk 05:11, 30 May 2009 (UTC)

The above statement is entirely incorrect, and the change was based on the advice from FSF licensing that the GPL v3 for that question applied to GPL v2, but apparently FSF have no interest in changing the GPL v2 FAQ. -- Jmmorgan 07:14, 30 May 2009 (UTC)

GPLv2 is required of any software using the SWORD library. The intention in picking the GPLv2 was that it was viral and did/does not allow for front-ends to be anything other than GPLv2. Even if the FSF's lawyers say that a front-end can have a license compatible with GPLv2, it does not change the intention. We can easily add such a sentence to clarify our intention. BTW, the goal in all of this is to glorify God.--Dmsmith 00:46, 31 May 2009 (UTC)

This is true, and of course any bundle must as a whole be available under the GPL v2. As I have stated before, the reason I take the position I have is because I object to other people being attacked because their conscience tells them to use an entirely legal, more permissive license for their own code (such as public domain). -- Jmmorgan 09:05, 31 May 2009 (UTC)

This is a strawman argument. No one has criticized anyone's choice of license for their own work, including more permissive licenses, including licenses such as BSD & public domain. I've written plenty of code under more and less permissive licenses, including plenty of BSD code that I've written for CrossWire specifically. The problem comes when writing code that is not entirely one's own, as is the case with any derivative of Sword, such as any front end that makes uses of any Sword code, including headers or derivatives thereof. These are derivative works under US law and thus must obey the licensing restrictions placed upon them by virtue of their authors' choice to use a GPL component. Any code completely free of Sword code or calls to Sword code may be released under any license its author likes (assuming it is also free of other license encumberances), but that very obviously does cannot constitute a Sword front end. Therefore, all Sword front ends must be GPLv2 licensed, as this page states. --Osk 03:11, 3 June 2009 (UTC)

Parallel commentaries

What is the point of having parallel commentaries? Parallel bibles help you compare similar, yet different translations. Commentaries are never similar enough that they need comparing specifically; the ability to have side by side windows ought to be enough. (and if not, then dictionaries ought to display parallel as well...) Benpmorgan 08:08, 30 May 2008 (MDT)

I agree, but I would guess that side-by-side commentary windows was all that was meant by "parallel commentaries". I don't think it really matters whether this is accomplished in multiple (MDI-type) windows, as in BibleTime, or in a single window with multiple columns, as in the Bible Tool (swordweb). Osk 12:11, 30 May 2008 (MDT)

I think it can be useful to have a commentary displayed along side another commentary or Bible. Because of "linked" entries, laying out in parallel is more difficult in HTML table cells. But it can be accomplished with rowspan. --Dmsmith 12:38, 30 May 2008 (MDT)

Support for vertical script ?

The Inner Mongolian NT is written in vertical script. Now there's a challenge to the technical minded! David Haslam 10:19, 20 July 2008 (MDT)

This falls under the category of things we would let Graphite handle (which reminds me that it should go on the Feature List if it isn't yet...). If Graphite can flow vertical text, then we would depend on it to handle this. Failing that, we don't have the expertise (desire?) to write our own layout engines. --Osk 11:27, 20 July 2008 (MDT)

Headings (canonical and non-canonical)

Might it be desirable to be able to toggle headings on and off, though leaving canonical headings (such as Psalm titles) displayed? What do other users think? David Haslam 12:42, 22 July 2008 (MDT)

This is what BPBible does - and I imagine others would as well. Sword's headings filter leaves canonical headings in - though the frontend could still opt not to show them. Benpmorgan 17:23, 22 July 2008 (MDT)

Building on what Ben said, if the attribute canonical="true" is present on the <title> element, the OSIS heading filter will not hide it. --Dmsmith 11:33, 23 July 2008 (MDT)

T9 Search

What does this mean? T9 is a way that a user can quickly enter dictionary words. Is this a search feature or an input feature? How would it be ideal for a full-featured front-end? Also, T9 is patented. Isn't it likely we cannot use it? --Dmsmith 11:41, 23 July 2008 (MDT)

I just removed the T9 stuff. The patent would be reason enough, but I think T9 (or a similar technique) is really of very limited use within Sword. There's a lot of this sort of material in the FeatureList, and someone should probably go through it and erase the inappropriate stuff. We should also probably add a new list of features expected of a full-featured frontend (which is what this list was intended to be before it became a wishlist). --Osk 17:58, 23 July 2008 (MDT)

Portability

Suggesting that the ideal frontend will support a large variety of platforms including Java ME is not only unrealistic, but is probably counterproductive (I suspect it is impossible to make one frontend that is ideal for both a Java ME environment and a standard Windows environment for example, though it might be possible to make a family of frontends that have some commonality). -- Jmmorgan 06:26, 30 September 2008 (MDT)

SWORD and implementation specific Features

Some of the things in the list are very SWORD specific, and don't really make a difference to the user. For example, "Ideally the different SWORD search engines would be supported." What is needed is that all the desired types of searches are supported - it doesn't matter in the least how they are implemented.

Other things are very specific to a particular implementation model, whereas the ideal application might be able to completely skip that model and come up with something more useful (examples being "Users should be able to manage bookmarks in a tree list.", "Search results output to the main window, not just in the search dialog, to allow for saving search results as a "verse list" and utilizing all the features available (such as cross-references and dictionary lookup)" [some of those things can surely be achieved without going into the main window, while others won't necessarily be supported even in the main window], "Hyperlinked scripture references"). -- Jmmorgan 06:39, 30 September 2008 (MDT)

IBT software based on SWORD technology

I propose to re-instate an item about the MK Holy Bible software available from the Institute for Bible Translation (IBT) that I posted in March, under the heading Non-CrossWire Frontends based on SWORD Technology. There is no ban on reporting this. It is freely advertised on the IBT website, and I also have personal contact with IBT and the program developer. David Haslam 12:34, 17 June 2009 (UTC)

Support for the OSIS transChange tag for attribute types other than "added"?

In OSIS, there is a <transChange>, translation change, element to indicate a departure from a literal rendering of the source text. This happens most often when words are added to a translation to make the meaning of the text clearer or when the grammatical structures of the translation language do not offer same tenses for example, as the source language. These are entered using the type attribute. If the user encounters a change in translation that is not covered by these values, use the OSIS attribute extension mechanism, "x-" in front of the name of your value for this attribute.

• added – Words added.
• amplified – More than addition of words to smooth out a translation.
• changed – Words are changed in the translation, such as modern spellings.
• deleted – Words that appear in the original but not in the translation.
• moved – Words that are moved to better represent the meaning of the text being translated from their original order.
• tenseChange – Indicates a change of the tense from the original to one that occurs in the translation language.

Most SWORD frontends support the transChange "added" type, by rendering the added words in italics, as in the KJV.

Do any frontends include support for other transChange types listed above? David Haslam 12:13, 17 July 2009 (UTC)

While front ends have the option to otherwise modify the markup they receive from the engine, transformations such as this are primarily the responsibility of the engine. Front ends using the OSISRTF filter will render all types as italic. Front ends using the OSISHTMLHREF will render "added" and "supplied" (an older form of "added", no longer supported) as italic and "tenseChange" with a preceding asterisk. Practically speaking, I'm unaware of any value other than "added" having ever been employed. So adding support for additional types across the board would be trivial, but we won't do it unless there's an actual need--and then we would need to decide how precisely to render other values distinctly. --Osk 00:56, 18 July 2009 (UTC)

Notification of superseded modules that have been replaced by a renamed module?

The conf file has a field that can be used to identify if a module supersedes an earlier module. AFAIK, none of the front-ends pick up this automatically, in order to notify the user that he still has the superseded module (with the older name) installed. This might be a desirable feature. Please discuss. David Haslam 14:19, 9 January 2010 (UTC)

Languages that don't space words?

One of the search feature bullet points is as follows:

• N-gram searching (needed for languages that don't space words, such as Vietnamese.)

Q. Which Vietnamese script does this observation apply to? David Haslam 14:45, 9 January 2010 (UTC)

"Line breaking becomes more difficult if scripts do not have word breaks, as in Tibetan and Thai, or if the word break is represented by a character rather than a space. Ethiopic is an example of using a character rather than a space: the Hulet Neteb (፡) is used between words in place of white space, unless there is other punctuation which acts as a word break. (This is also an excellent illustration of how computers have changed a script. With the advent of computing, Ethiopic is now usually written on computer with white space between words. When handwriting, however, people typically still use the Hulet Neteb.)" [1] David Haslam 15:29, 9 January 2010 (UTC)

The Tarshish/Tharshish example

Of course, one can find all instances of both Tarshish and Tharshish by a search for 'arshish', but the point in citing this example is that the user may be totally unaware of the variant spelling. David Haslam 18:46, 9 January 2010 (UTC)

Search for empty verses

Currently to do this requires the use of the separate utility, emptyvss.exe and piping the results to a text file, then editing the file to remove [say] all the OT references for a module that is NT only, then using this as a verse list file that can be opened with a front-end such as Bible Desktop. And for this to be meaningfully useful, the front-end must be capable of displaying Bible modules in parallel, so that the translation with missing verses can be compared with [say] the KJV. David Haslam 19:56, 9 January 2010 (UTC)