[jsword-devel] Progress toward 0.9.9

[Joe Walker]

On Sat, 05 Mar 2005 11:27:10 -0500, DM Smith <dmsmith555 at yahoo.com> wrote:
>  I think that we are getting close to a 0.9.9 release.
>  Here is what is left (according to Jira):
>  (Beyond these, we will need to do a thorough testing to see what bugs are
> present and fix those.)
>  JS-1 Implement match in lucene using wild cards
>  
> Joe, take a look at lucene's fuzzy match operator. It is pretty cool. It
> will find words that are within a reasonable edit distance to the word that
> is searched.

OK

>  JS-8 Make index creation happen at a better time
>  
> I think that this one has improved enough that it can be moved to 1.1

Agreed.

>  BD-1 Cancel download is broken
>  
> Indexing has the same problem. A simple interim fix would be to remove the
> ability to cancel a download or indexing. This will minimize the problem
> that if either of these do not go to completion that the install will be
> corrupted, requiring manual intervention. It will still happen if the user
> closes the program, the program abnormally terminates, the computer reboots,
> ....
>  
>  A better solution would be to do the work to an alternate name and rename
> upon completion. When the job starts it could look for previous failed
> attempts and clean it up if needed.
>  
>  There are probably other solutions as well.
>  
>  What should we do for 0.9.9, for 1.0 and beyond?

I don't think we can push this past 1.0, simply because indexing takes
so long, many people will badly need to cancel out.
I think current is so much better than 0.9.8 that it makes sense to do
another release, so this maybe goes between 0.9.9 and 1.0?

>  BD-4 Just shows the version, seems kinda pointless
>  
> I am willing to let this one slide to 1.1. But if we do something for the
> release:
>  
>  What should this show? Some thoughts: credits, contact info, urls to
> website, overview of program, date of build, copyright/license statement.
> WRT to credits, a lot of people over time have contributed small amounts
> that were individually significant and together were very important. Having
> a list of key contributers, IMHO, would slight these efforts. Besides, I
> don't care if my name is on the program or not.
>  
>  Whatever we do, our internationalization framework will need to be used.
>  
>  Should these be on separate tabs or in a scrolling box?

Some build info should be easy to add, and would be in keeping with
about boxes. I'm not fussed about my name in (all be it dim) lights,
and I've just tried to write a list of contributors, and it's not easy
there are are a small (~10) code contributors, but many more that have
done real good stuff list writing user manuals and contributing ideas,
etc.


>  BD-5 Create help.
>  
> I think that if we add the url to where on the web that help can be found,
> this could be moved to 1.1 Under 1.1 we would be adding the ability to bring
> up a document in an appropriate program. I think that Java Activation
> Framework may provide the mechanism. We could put the document in the jar
> and extract it to the ~/.jsword directory and view it from there.

Agreed.

>  BD-8 some nt verses badly displayed in ot refs
>  
> Not sure where this is, but if I had an example, I would be glad to look at
> it. I think it is probably a trivial change to the xslt.

Can't dig up an example straight away, but I seem to remember that the
real problem is the source data. I think we may well have not option
but to point the finger at the modules.

>  BD-9 Notify the user when a single testament bible is installed.
>  
> I don't want to have a popup when the install is finished. We had this and
> it led to some sneaky bugs. Either we know it before hand (i.e. it is a
> reliable field in the conf) or we figure it out before hand (i.e. check the
> website for the corresponding nt.* or ot.* files), but we don't notify after
> the fact.
>  
>  The LCSH (Library of Congress Subject Heading) in the conf already provides
> this. The problem is that this field can contain anything. So it cannot be
> used programmatically. It typically is of the form:
>  Bible. O. T. German
>  It is not internationalizable.
>  
>  We could put the LCSH in the popup that provides the size of the download.
> But, I would like an internationalizable solution.
>  
>  My vote would be to change the conf, but we have not gotten very far with
> those suggestions before (i.e. download size, install size, ...) Basic idea
> would be to add Scope= to the conf. This field would be a listing of one of
> these forms:
>  OSISref -- Just contains what is referred to by the OSISref: a single book,
> chapter or verse.
>  OSISref-OSISref -- Contains everything from the first OSISref to the second
> OSISref, inclusively.
>  or a comma separated list of these.
>  The default would be Gen-Rev.
>  
>  If this is the direction we take, then I think that we should move it to
> 1.1.

Need to think about this some more.

>  BD-11 Selection not maintained when blur button is clicked.

>  BD-34 Switch to the right dictionary/commentary/... when a link is
> activated.

> I am working on this one right now. Probably will take a couple of weekends.

Cool.

Joe.