Sketch Editor

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...rt.html

mail to: daisy-81qHHgoATdGcMQoVcdA18UB+6BGkLq7r@public.gmane.org
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

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.=20

(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),=20
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=C3=A4nni wrote:
> Hi Karel
>=20
> 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=20
> my code.
>=20
> A possible workaround would be to completely integrate the source files=
=20
> of the classes I need from JHotDraw into my SektchApplet (The same way=20
> you suggested in an earlier mail).
> This way JHotDraw would be built from source as part of building the=20
> applet and there would not be a separate JHotDraw jar file. On the othe=
r=20
> hand the Sketch applet jar would again contain both "ch.ergon.**" and=20
> "org.jhotdraw.**" classes.
>=20
> Would this workaround be a possibility for you? Or can you think of=20
> another solution?
>=20
>=20
> Regards,
> Michael
>  ________________________________________
_______
> daisy community mailing list
> Professional Daisy support: http://outerthought.org/en/services/daisy/s=
upport.html
> mail to: daisy-81qHHgoATdGcMQoVcdA18UB+6BGkLq7r@public.gmane.org
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
 ________________________________________
_______
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/sup=
port.html
mail to: daisy-81qHHgoATdGcMQoVcdA18UB+6BGkLq7r@public.gmane.org
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

ps: I mailed one of the JHotdraw developers (Wolfram Kaiser) to ask
their opinion on the matter.

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:
>=20
> (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 bugfixe=
s
> 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.=20
>=20
> (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.
>=20
> 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 usin=
g
> JHotdraw wins.  OTOH, if I make changes to JHotdraw in situation (b),=20
> those changes are much more unlikely to get shared with others (not tha=
t
> I'm selfish, I just have much to do and am likely to move on after
> fixing things.
>=20
> Regards,
> Karel
>=20
>=20
> On Thu, 2008-06-12 at 15:04 +0200, Michael H=C3=A4nni wrote: 
n=20 
es=20 
y=20 
her=20 
=20 
/support.html 
>  ________________________________________
_______
> daisy community mailing list
> Professional Daisy support: http://outerthought.org/en/services/daisy/s=
upport.html
> mail to: daisy-81qHHgoATdGcMQoVcdA18UB+6BGkLq7r@public.gmane.org
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
 ________________________________________
_______
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/sup=
port.html
mail to: daisy-81qHHgoATdGcMQoVcdA18UB+6BGkLq7r@public.gmane.org
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

I think you have to contact Werner Randelshofer=20
(http://sourceforge.net/project/memb...roup_id=3D12679). I=20
contacted him, as he seems to be the leading developer at the moment.

Karel Vervaeke schrieb:
> ps: I mailed one of the JHotdraw developers (Wolfram Kaiser) to ask
> their opinion on the matter.
>
> On Thu, 2008-06-12 at 15:28 +0200, Karel Vervaeke wrote:
>  =20 
t, 
es 
m 
ng 
at 
n=20 
es=20 
y=20 
her=20 
=20 
/support.html 
support.html 
>  ________________________________________
_______
> daisy community mailing list
> Professional Daisy support: http://outerthought.org/en/services/daisy/s=
upport.html
> mail to: daisy-81qHHgoATdGcMQoVcdA18UB+6BGkLq7r@public.gmane.org
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>  =20

 ________________________________________
_______
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/sup=
port.html
mail to: daisy-81qHHgoATdGcMQoVcdA18UB+6BGkLq7r@public.gmane.org
list information: http://lists.cocoondev.org/mailman/listinfo/daisy

Hi

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

<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.=20
</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:
>=20
> (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 bugfixe=
s
> 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.=20
>=20
> (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.
>=20
> 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 usin=
g
> JHotdraw wins.  OTOH, if I make changes to JHotdraw in situation (b),=20
> those changes are much more unlikely to get shared with others (not tha=
t
> I'm selfish, I just have much to do and am likely to move on after
> fixing things.
>=20
> Regards,
> Karel
>=20
>=20
> On Thu, 2008-06-12 at 15:04 +0200, Michael H=C3=A4nni wrote: 
n=20 
es=20 
y=20 
her=20 
=20 
/support.html 
>  ________________________________________
_______
> daisy community mailing list
> Professional Daisy support: http://outerthought.org/en/services/daisy/s=
upport.html
> mail to: daisy-81qHHgoATdGcMQoVcdA18UB+6BGkLq7r@public.gmane.org
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
 ________________________________________
_______
daisy community mailing list
Professional Daisy support: http://outerthought.org/en/services/daisy/sup=
port.html
mail to: daisy-81qHHgoATdGcMQoVcdA18UB+6BGkLq7r@public.gmane.org
list information: http://lists.cocoondev.org/mailman/listinfo/daisy