[jsword-devel] More changes

DM Smith dmsmith555 at yahoo.com
Thu Sep 2 09:05:06 MST 2004


Patch to follow (I am testing it before I send it):
1) I changed the management of the initial size of the Desktop. If it 
exceeds the dimensions of the screen, it opens in Maximized, if the 
platform supports it. This also required a change to the code to center 
the window so that it would recognize that the window is maximized. This 
is a JDK 1.4 feature. The problem that I was addressing was that in 
WinXP, I was using the screen size and it was centering it and the 
status bar was under the task bar. Now it is correct. At least for 
WinXP. Please let me know if it is wrong for Mac or Linux

While I was looking at the documentation for resizing windows, I found 
that it is possible via 2 different mechanisms to do full screen. That 
is an application that fills up the entire screen, without window 
decorations. Would there be any interest in having this as a user 
option? I think it is fairly simple to do.

2) Jacky Cheung noted the problem that Strong's numbers are not properly 
rendered in GBF bibles. I have fixed that. The problem was that JDom 
does not use strings for text elements. The code was looking for String. 
I have fixed that and found that in many other places we were looking 
for String as an element. I fixed those as well.

3) Jacky also noted that hyperlinks use a lot of CPU. I have been able 
to verify that they do indeed use a lot of CPU, but I have not been able 
to get my machine to freeze because of it. In looking into the problem, 
I saw a couple of optimizations which I did. The basis problem is that 
the management of hyperlinks was being done in Desktop.java and not in 
TextPaneBookDataDisplay (TPBDD). So Desktop.java needed to use the 
event's getSource to manipulate the underlying document. Because it was 
listening to several different documents, it could not optimize based 
upon the document.

The code in Desktop did a few things:
a) it forwarded the event to the status bar.
b) it identified whether the event was an enter or leave event and 
styled the link ala CSS rollover (since jdk 1.4 does not support it)
c) on an activate event of #loc it scrolled the document to that anchor.
d) on activate events (not #loc style) it determined whether to open a 
commentary, dictionary or another bible view pane.

The performance problem is in b).

With regard to placement of functionality:
For a) the status bar should be listening for its own events and should 
not  rely on Desktop to forward them.
b) and c) are best done with the document (i.e. should move to TPBDD).
d) needs to be done in desktop since it is the place that knows about 
the parts of the desktop.

So I did these refactorings.
Now TPBDD needs to fire events to listeners (status bar and desktop). 
And they only do what they need to do and nothing more.

While I could have used a forwarding technique of forwarding the event, 
I chose to implement a different event. I did this to make it more 
obvious in the code what was going on.

Because each TPBDD listens for its own hyperlink events, it can be 
optimized. I have the code memorizing the location of enter events, the 
style to be applied, and the underlying styled document.

The net is that it is faster, but still very CPU intensive. I would be 
interested to hear whether it clears up the freezing of the application.

4) I found a bug in ThML where scripture references were being changed 
into <div osisID="reference">reference</div>. According to OSIS 
documentation and some conversations with OSIS folk,  the osisID on a 
div is not to be used for scripture references. So I changed it to 
<reference> tags.

I found the problem in GerElb1871. And it brought up another issue. When 
I clicked on one of these references, it bought up a new BibleViewPane, 
but in my default KJV.

The link in ThML was:
<scripRef passage="Ezra 8:10" version="GerElb1871">v 10</scripRef>
So specifically, it is referring to chapter and verse in the same 
version of the bible. Not in the KJV.
According to the OSIS documentation, an OSIS id can include the work. 
Something like osisRef="GerElb1871.Ezr.8.10"

Anyway, what should we do? Ultimately, I think we should add support for 
xrefs to hit the same bible. I don't think it is a big deal in the short 
term, if we view Bible Desktop 1.0 as a default bible reader. In this 
case a German reader having GerElb1871 as their default will get the 
correct view.

The other issue I encountered was that the verse was in the current 
BibleViewPane and should have been treated as a #loc style. This is not 
something that could have been known in the generation of the OSIS from 
ThML. It would need to be done either in TPBDD or Desktop.

5) I improved the DisplaySelectPane. It now solves Mark's problem of not 
being able to move the divider to the left. And it also solves the 
flipping issue that Don noted: The card does not change under program 
control, but under user control.

6) I decoupled some code that was tightly coupled by introducing a 
KeyChangedEvent and KeyChangedEventListener. I move the passage sidebar 
code out of SplitBookDataDisplay and into its own class, KeySidebar. 
Now, the KeySidebar, the BookDataDisplay and the DisplaySelectPane are 
loosely coupled, and only know of each other by events.

7) The Bible combo box now shows a tooltip not just for the elements in 
the list but the one that is showing in the box itself.

8) I added the initials of the book to the beginning of the name of the 
book as it is displayed. In the installer, it is not alphabetized by 
initials but by still by name. If this is something that others don't 
want to see, I will be glad to make it a user option.

9) I commented out config options that are not useful for the target 
audience of 1.0. This includes all the ones that were a pick list of 
one. (This required a minor change to get the LAF correct.) As 
developers, we can modify our local copy to change the config options. 
The ideal way to have done this would have been to improve the config 
code to prune these out based upon whether the user was a developer or 
not and whether the option represented a real choice.

I also re-ordered the options and placed a few in different places.

10) I fixed a problem with the config's boolean field as it was looking 
for a doYes and a doNo. I think that we still have a problem here as 
actions are fully shared. So if we have two different Yes options, 
firing one may fire the other. We may need to add the ability to clone 
the actions to fix this if it becomes a problem.

11) I changed "Close" to "Clear" and "Close All" to "Close Others". We 
may still need a close that is active only if there are more than one 
BibleViewPanes or that does a clear if it is the last one. The idea here 
is that you should not be able to close the last one, but you may wish 
to clear it for re-use. The problem I was trying to solve was the 
numbering of the tabs. If you were to choose "Close" or "Close All" when 
the program starts up, 10 times in a row and then create a new 
BibleViewPane, it would have a name like "Untitled 12" and the other one 
would have a  name of "Untitled 11". I find this surprising. Anyway 
there is more work that needs to be done to make it more "usable".

One thing that I want to fix is the clicking on a daily reading link 
should not open a new BibleViewPane, if there is one that is clear. 
Right now, when you open one at the beginning of the program you see two 
tabs, one is unused and the other has the passage. I also want to fix 
the problem that someone reported that it opens a BibleViewPane even if 
that reference is already in one. I want to search for the reference in 
existing BibleViewPanes and bring that one to the front if it exists. 
Otherwise bring a new view.

12) I changed the font for View Source to be the one the user picked to 
display the bible. I discovered that I could not view some source unless 
I had a font that could display the Unicode (Chinese in this example. 
But it is also true of Hebrew and Greek as well).

13) I added the recognition of I/II/III as a book name prefix. In this 
case an intervening space is required.

14) Updated bugs.txt.



More information about the jsword-devel mailing list