[jsword-devel] flashcards updates

[DM Smith]

Troy,
    I have been looking for kerning problems. I don't see anywhere where 
one letter obscures the next. I did find some descent clipping problems. 
Every text box that has a normal height (e.g. the list of flash cards, 
the status bar, the answers [when flipped and window shrunk too much]). 
Is this what you were referring to? I see that the insets were changed 
on the QuizPanel and that the "front" is not clipped. Is this where you 
saw the problem?
    Anyway, I am trying to solve the above clipping problems and put the 
editor on the Edit tab.
DM

DM Smith wrote:

> Give me an example of what the clipping looks like and I can try to 
> fix it.
> While I have 7 credit hours of hebrew, I don't remember much of 
> anything. So I need some guidance as to where to look.
> Where is it being clipped? (Which tab?) What font are you using? 
> Anything special?
>
> If you want, I can add the editor to the EditPane to the right of the 
> list of FlashCards. The way it would work is that if anything is 
> selected, it is selected to modify. Otherwise, the editor starts out 
> blank. There would be an add button and the obligatory recognition of 
> the return key in the "Back" widget to do the add. We could also add a 
> delete button and get rid of the menu. This would be simple to do.
>
> Troy A. Griffitts wrote:
>
>> DM and John,
>>     Thanks for all the work!  It looks really great.  I'm still 
>> getting used to the new interface.  I personally liked my layout 
>> better for the editor (of course :) ), as one didn't have a floating 
>> editor dialog over the word list and could scroll thru and change 
>> things with less clicks.  But your interface may just take a little 
>> getting used to.
>>
>>     The layout for the QuizPanel no longer works in JBuilder.  I'm 
>> worthless when it comes to modifying, say, a gridbaglayout without 
>> GUI editor help, so you own it now! :)  So, can I get ya to try to 
>> figure out how to add a little room for the font kerning in the 
>> Hebrew font. It's clipping vowel points.
>>
>>     I'll let ya know how the editor goes this week as I enter in a 
>> few more Hebrew lessons.
>>
>>     This must have taken a considerable amount of time.  I really 
>> appreciate all you and John have been doing.  John, the Greek 
>> keymappings are wonderful and I'm sure will facilitate a broader 
>> audience!  Mounce is probably the most common Greek textbook; those 
>> lessons are very much appreciated!
>>
>>     In Him,
>>
>>         -Troy.
>>
>>
>>
>> DM Smith wrote:
>>
>>> Well I have taken a look at replacing log4j with Java's logger. The 
>>> goal is to make common as light as possible (wrt to dependencies on 
>>> outside jars) so that other projects would not hesitate to use it.
>>>
>>> It looked like it was a pretty simple change, but there is a snag. 
>>> It does not properly report the location of the logging.
>>>
>>> First let me describe how the two map to each other:
>>> Both have the same notion of getting a logger named via the class name:
>>> log4j is Logger.getLogger(Class clazz)
>>> java is Logger.getLogger(String classname)
>>>
>>> Both have predefined levels in a Level class.
>>> log4j: FATAL,ERROR,WARN,INFO,DEBUG
>>> java: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST
>>> and both have convienence functions for these methods. I see mapping 
>>> them from left to right and not using FINER and FINEST.
>>>
>>> Both have:
>>>    the same notion of inheritance of logging
>>>    the same notion of a root logger
>>>    the same notion of configuration by a properties file
>>>    the ability to set the global logging level
>>>
>>> Differences:
>>> log4j allows for a Throwable to be passed into the convienence 
>>> methods (e.g. log.warn("message", throwable) and it appends it to 
>>> the message.)
>>> java requires the use of logger.log(Level.WARNING, "message", 
>>> throwable)
>>>
>>> log4j can be wrapped and produce class, method and line of the 
>>> caller. Java's logger does not dig into the stack trace to determine 
>>> the nearest match to the logger's class.
>>>    Solution: in the wrapper get the stack trace and figure out the 
>>> calling class, method and line. Not very easy but can be done.
>>>
>>> log4j writes to stdout, while java writes to stderr. This is 
>>> configurable in log4j and I think in java. My opinion is that stderr 
>>> is better as it is not buffered.
>>>
>>> log4j has single line output, java has 2 line output. This is 
>>> configurable in log4j and I think in java.
>>>
>>> I am going to check in the change to .../common/util/Logger.java so 
>>> you can see the differences. I handled the stack trace.
>>>
>>> Given our use of log4j, I don't see any advantage of it over Java's 
>>> logger.
>>>
>>> My recommendation is to migrate to Java's logger directly and not 
>>> wrapped (as opposed to solving the wrapping problem).
>>>
>>> I'll be looking into configuring the logger to mimic the output of 
>>> log4j.
>>>
>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>