<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
It would be good as I have had to make changes to both copies! I don't
think it is at all good to maintain two slightly different copies.<br>
<br>
The issues as I see it are as you noted. When I started, FlashCards was
93K delivered. Now it is about 150k. (The difference is mainly the
additional lessons) The other jars add significantly to the size of the
download. I don't know if this is a big deal or not. Other than the
time of the download, it should be transparent to the user.<br>
<br>
And the delivered jars need to be signed with the same jar signer key.
FlashCards could take a point in time copy of the jar and sign that.
Just like we do for 3rd party jars.<br>
<br>
Also, we have the issue of the mixed development environment (CVS and
SVN; different projects).<br>
Again a snapshot approach would work and minimize breaking FlashCards..<br>
<br>
As to activation and junit. These are not a part of the delivered
environment. They may be needed in a development environment.<br>
<br>
As to jdom, I think that it is permissible to use common.jar w/o
jdom.jar. The loading of classes is dynamic and the runtime should not
complain of jdom missing if it is not needed. It may be needed in a
development environment.<br>
<br>
As to log4j, it seems that Java logging is a reasonable replacement. It
is only used by one file: Logger.java. So it would be real easy to get
rid of. And it would save 345K. The bigger issue is should commons do
any logging? My personal bias is that general utility classes should
almost never log output or write to stdout/err. FlashCards is ready to
handle exceptions, but not setting up of logs. W/ log4j logs are set
up/managed by a log4j.properties file.<br>
<br>
As to commons-lang. the savings would be 166k. I don't think we use
that much of it. 42 times total and only a few of the classes.<br>
<br>
Joe Walker wrote:
<blockquote cite="mid5dd47426040917100468cb305@mail.gmail.com"
type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:dmsmith555@yahoo.com"><dmsmith555@yahoo.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
jsword-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
</pre>
</blockquote>
</body>
</html>