[jsword-devel] More changes coming

Joe Walker joseph.walker at gmail.com
Fri Sep 17 10:04:39 MST 2004


Excellent - I've done a very quick scan across the code and it all
seems to make good sense and seems to work OK at a brief tour.

On a side issue:
It would seem sensible to make common useable for flashcards as well
as bibledesktop. The biggest issue was jar files, I think?

The jar list in the .classpath includes:
- activation (but I think this is only needed to compile tar, and not
needed at runtime so we could probably remove this)
- commons-lang (which I would guess we used for String manipulation
and not a lot else. We could copy across the code if it would make
life simpler. On second thoughts there could be some Enum use too)
- jdom (could be harder to get rid of. I see it has just gone 1.0 by
the way, maybe worth updating)
- junit (not needed in 'live')
- log4j (we could swap to java.util.logging easily)

Joe.

On Tue, 07 Sep 2004 14:58:46 -0400, DM Smith <dmsmith555 at yahoo.com> wrote:
> I was working on the "reuse of tabs" issue in bugs.txt.
> 1) The program would close a BibleViewPane, even when it was empty. The
> net end-user effect was that the tab was renamed from Untitled 1 to
> Untitled 2.
> 2) In MDI view it was possible to use the "X" close button on the window
> to close the BibleViewPane. But changing back to TDI mode would have the
> BibleViewPane still there. The problem was that Desktop.java maintained
> a cache of views and the close on the InternalJFrame did not change that
> list.
> 3) When a user clicked on a daily reading, without having done anything
> else, the passage was open in a second tab, leaving the other one
> "Untitled 1". It should have use the empty one.
> 4) When a user clicked on a daily reading, it always opened another tab,
> even when it was already in a tab. It should have found that it was
> already there and brought it to the front.
> 
> As a general design issue, there was tight coupling between the code
> that managed the view layout and the manipulation of BibleViewPanes.
> 
> Here are the changes I made in fixing these 4 problems.
> I first split Desktop.java into two parts. The one part builds the
> screen and holds the relationship between the BibleViewPanes, and the
> reference pane. The other manages the layout and creation of views.
> 
> I made it generic, having no knowledge of BibleViewPane, and it can be
> used for any application that could use a MDI of windows that all hold
> the same thing.
> 
> I decoupled it from the rest of the code by using events to communicate
> changes and by introducing a few interfaces that represent the key
> contract that this new code needs to care about.
> 
> Specifically, I created a ViewManager which could switch between a TDI
> and a MDI layout. The current layout needs to be able to request and add
> a new view. To remove an existing view. To make views available to the
> rest of the program. It turns out that the relationship between a tab or
> internal window and a view is that the tab/window needs to get its title
> from the view. For this I created an interface Titleable.getTitle().
> When removing a view, the current layout cannot remove the last one, but
> has to clear it instead. (The old code would remove the last one, note
> that there no longer is one and then create a new one.) This required an
> interface Clearable w/ clear and isClear. To create a new view, the
> ViewManager needs to be able to createView(). I created an interface
> ViewGenerator for this. When the ViewManager is created, it is passed a
> ViewGenerator.
> 
> To solve the problem of closing an InternalJFrame, I had removeView fire
> a ViewEvent for viewRemoved(). Listeners could then respond
> appropriately. Initially, I did not have this and the program looked
> like it behaved correctly, but I found that I had a memory leak in that
> these removed BibleViewPanes were being held in listener lists.
> 
> I moved all this generic code from BibleDesktop to common.swing.desktop.
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>


More information about the jsword-devel mailing list