[jsword-devel] Before 1.0

Aleksander Rozman - Andy jsword-devel@crosswire.org
Wed, 31 Mar 2004 16:51:30 +0200


At 31.3.2004, you wrote:
>Aleksander Rozman - Andy wrote:
>>Hi !
>>
>>I will comment on both this comments and originla comments.
>>
>>>It has been fun working on JSword. There is a lot of excellent 
>>>architecture and code.
>>>
>>>I think that it may be good to do a .97 release as .96 does not work.
>>>Kind of a second beta. This way non-programmers can help us discover 
>>>bugs to fix.
>>>
>>>Bible Desktop is fine w/ me.
>>>
>>>There is still one major startup issue, which I have not mentioned 
>>>before, that I think needs to be tackled. The management of options 
>>>needs some more work. What is there is excellent. I really like how it 
>>>is dynamically built.
>>>
>>>The notion of options needs to have the notion of program defaults and 
>>>have that reflected in the options dialog. There are some defaults that 
>>>cannot be simply represented in a static file: such as Font, Look and 
>>>Feel, home directory, default paths. When options are saved and no value 
>>>is given, then it should not be saved as empty but as using the default.
>>
>>Look and feel should be set to default LF for OS.
>
>Done.
>
>>Have we done anything tu support skinlf so far? Thoose who don't know 
>>skinlf is LF management sistem which supports multiple LF, not only just 
>>those made for it, but many others (I think GTK, in work is supoer for 
>>Windows XP Themes, ...)
>
>I haven't seen this in the code.


It's not in code, but this library should be added, since it supports most 
of themes, LF types arround. It's little harder to set than normal LF.




>>Maybe we should supply fonts with Desktop Bible (or how is new name)...
>We are defaulting to the font used for JLabel, which in the case of 
>Windows XP is Tahoma.
>This font when set to an appropriate size is very readable. I presume that 
>for any
>Java GUI to look good the JLabel font will be excellent.
>
>Yesterday, I looked at the Hebrew and the text was excellent. I will be 
>looking at
>Greek later today. If there are specific font issues on other platforms 
>then I think it would make sense to deliver other fonts.
>
>I think we will get feedback after a .97 release.
>
>>
>>>Vines shows internal markup around verse references.
>>>
>>>2 of the Backends are stubbed out, but books for them are listed. I 
>>>think JSword should only show books it can actually do something with.
>>>
>>>For a 1.0 release, I think the "programmer" helpers, such as debug, view 
>>>html, osis and ghtml, need to be hidden.
>>
>>Maybe we can give an option to start DB with, like -debug in which this 
>>options will be added.
>
>The problem with flags is that it is not Java's preferred way of passing
>options to programs. I think the mechanism was provided to make porting
>from C/C++ easier. Java gives preference to property files (which is used
>for startup options) and to JNDI (which is not appropriate here).
>
>I think the way the code is setup now, it would be appropriate to use
>properties to do it. If in the ~/.jsword directory there were a 
>debug.properties
>then debug would be turned on and controlled by its contents.
>
>I was thinking of allowing programmers to hand edit the desktop.property file
>and add a debug property there. But while it is only for developers, hand 
>editing
>is error prone.
>
>For a delivered debug mode, I think that console messages need to be 
>re-targeted to a text widget.
>
>>
>>
>>>For post 1.0, I think pdf generation via xsl-fo would be good (Apache FOP).
>>
>>That would be great...
>>
>>
>>>Print. Helps definitely.
>>
>>That would be good, but I think probably not so easy to achive.
>>I have some code that might be helpful in this one...
>
>I have had lots of problems with printing JTrees. The scaling would cause 
>lines to be truncated in weird ways. Sometimes with ... and other times 
>just chopped short.

Why would you print trees? I was assuming we want to print text. Java has a 
weird thing about printting. You must use Graphics2D context to do it...



>When we get to print help will be greatly appreciated.
>
>If PDF is supplied, it can be an indirect means of providing print.
>
>>
>>>Full internationalization.
>>
>>Agree. As I said a long time ago, I don't think that implemnetation of 
>>I18N in DP is good, but that is just my opinion (memory).
>
>I18n and L10N will not be easy. The notion of MsgBase and Msg will help. 
>There needs to be a separation between messages meant for users and 
>messages meant for developers. The former need to be localized, the latter 
>don't. Developer messages should only be seen in details, or only by 
>developers (debug mode).
>
>I mention L18N, because in a recent project with Americans (who were 
>writing the program) and Australians (who wanted to use the program). The 
>Aussies did not like the spelling and wording that Americans used. We 
>tried to obtain consensus for a location neutral wording. But in the end 
>we realized that "We all speak English" was too simplistic. So we had to 
>localize as well as internationalize. We found that it was easier to add 
>support for localization at the same time as internationalization, than to 
>add it later.

This should be both done at the same time. But I have a problem with 
MsgBase/Msg types, most of it is memory wise, but other thing is that you 
have a lot of files with text lying arround, all open. Using static methods 
doesn't help either...


>But there are LtoR/RtoL issues. These may not need to be tackled unless we 
>are targeting delivery to a RtoL culture. (There are also Top to Bottom 
>from Left to Right and Top to Bottom from Right to left cultures.) The 
>basic rule of thumb is that layout importance needs to follow these directions.
>
>So to deliver to a Hebrew speaking Christian the Horizontal layout of the 
>menus will need to be flipped and anchored to the right. Some of Java's 
>layouts allow for setting the direction, which would help.
>
>When we get to I18N of actions, your suggestion below will probably need 
>to be followed. If memory serves me, resources are looked up during 
>initialization after the object has been initially constructed (i.e. after 
>calls to this(...) or super(...). Further, the mnemonics will need to be 
>language specific.
>
>
>........... Stuff deleted .................
>>We need to fix rendering of some bibles. I think I noticed one mail about 
>>that so maybe that is already fixed...
>
>I think this is fixed. (Except for RtoL of Hebrew verses.)
>
>>
>>Some of my concerns:
>>
>>- DP implementation: I think we should change DP implementation somewhat. 
>>We have class for each action, instead we should put all actions together 
>>in main DP class and make just one Action Listener. This is just memory 
>>concern, so it's not something that we need urgent. This would be 
>>probbaly helop with I18N, even if we keep it at current version.
>
>Andy, what is DP?

Sorry, I was meaning Desktop Bible here... So it would be DB, or Bible 
Desktop (BD)...

Take care,
Andy



>_________________________________________________________________
>MSN Toolbar provides one-click access to Hotmail from any Web page ­ FREE 
>download! http://toolbar.msn.com/go/onm00200413ave/direct/01/
>
>_______________________________________________
>jsword-devel mailing list
>jsword-devel@crosswire.org
>http://www.crosswire.org/mailman/listinfo/jsword-devel

**************************************************************************
*  Aleksander Rozman - Andy  * Fandoms:  E2:EA, SAABer, Trekkie, Earthie *
*     andy@kksonline.com     * Sentinel, BH 90210, True's Trooper,       *
*    andy@atechnet.dhs.org   * Heller's Angel, Questie, Legacy, PO5,     *
* Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender    *
*     ICQ-UIC: 4911125       *********************************************
*     PGP key available      *    http://www.atechnet.dhs.org/~andy/     *
**************************************************************************