[daisy] Sketch Editor

[Paul Focke]

Hi

I had a quick peek at the JHotDraw documentation in an attempt to figure
out why the developers advised to copy the code into your own project. 

<snip>
JHotDraw is a framework, and not an API. With new versions of the
framework, you likely need to adapt your dependent code. JHotDraw also
contains a lot of sample code and default implementations, which you are
unlikely to need in your application. And finally, the artwork which
ships with JHotDraw (for example the icons) may not match the style of
your application. Thats why we think it makes little sense to bundle
JHotDraw into a .jar-file, which can be put into the classpath of an
application.

We recommend putting the jhotdraw/src/main/java directory in the source
classpath of your project, and let javac find the classes which your
project actually needs. 
</snip>

So as you can see it's about the samples, default implementations and
artwork. I don't find samples and default implementations a good reason
not to use a jar. The artwork on the other hand seems like a valid
reason. It'd be great if the locations of the artwork could be
configured in some manner. Seems like a good step in the modularization
direction. Easier said than done of course.

Paul


On Thu, 2008-06-12 at 15:28 +0200, Karel Vervaeke wrote:
> I really don't see the point that the authors of JHotdraw are making.
> There are two alternatives:
> 
> (a) use JHotdraw as a library.  If I want to make changes to the applet,
> and I want to use the newest JHotdraw version (be it because of bugfixes
> or because I want new features), I can do so and I will have no problem
> changing my code to take JHotdraw API changes into account. 
> 
> (b) copy JHotdraw source code into the applet code and compile from
> there.  If I want to upgrade to the newest JHotdraw version, I have to
> find out which files have changed, copy the relevant files over to the
> applet.  If I make changes to the copied JHotdraw the next upgrade is
> going to be horribly painful:  I need to merge changes from JHotdraw
> proper with the copied JHotdraw code.
> 
> There even is added value for the JHotdraw project: If I want to make
> changes to JHotdraw in situation (a), I have to report my changes
> (bugfixes, new features) and wait for the next release - everybody using
> JHotdraw wins.  OTOH, if I make changes to JHotdraw in situation (b), 
> those changes are much more unlikely to get shared with others (not that
> I'm selfish, I just have much to do and am likely to move on after
> fixing things.
> 
> Regards,
> Karel
> 
> 
> On Thu, 2008-06-12 at 15:04 +0200, Michael Hänni wrote:
> > Hi Karel
> > 
> > I'm afraid you discovered a delicate problem.
> > I contacted the developer of JHotDraw.
> > He told me not to use JHotDraw as a library.
> > He told me, that each update of JHotDraw would also require changes in 
> > my code.
> > 
> > A possible workaround would be to completely integrate the source files 
> > of the classes I need from JHotDraw into my SektchApplet (The same way 
> > you suggested in an earlier mail).
> > This way JHotDraw would be built from source as part of building the 
> > applet and there would not be a separate JHotDraw jar file. On the other 
> > hand the Sketch applet jar would again contain both "ch.ergon.**" and 
> > "org.jhotdraw.**" classes.
> > 
> > Would this workaround be a possibility for you? Or can you think of 
> > another solution?
> > 
> > 
> > Regards,
> > Michael
> > _______________________________________________
> > daisy community mailing list
> > Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
> > mail to: daisy at lists.cocoondev.org
> > list information: http://lists.cocoondev.org/mailman/listinfo/daisy
> _______________________________________________
> daisy community mailing list
> Professional Daisy support: http://outerthought.org/en/services/daisy/support.html
> mail to: daisy at lists.cocoondev.org
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy