> Ah, yes... ofcourse... thought you mentioned a free version, like the
> jar that we distribute...
Actually, the jar that we distribute has a manifest that says Sun
Microsystems. So I assumed that it came from them.
I took a look at the implementation used for cdk. And clearly that version
is *su
In order to better fit with the cdk classes I converted all floats and
vecmath floats into doubles.
I went through and changed everything without looking at it too closely.
Afterwards, I loaded all sample files that I could to confirm that
everything still worked. The animations and vibrations see
On Sunday 01 December 2002 16:28, mth wrote:
> > Is it actually maintained somewhere?
> vecmath.jar is now included as a standard part of the Java3D API.
Ah, yes... ofcourse... thought you mentioned a free version, like the jar
that we distribute...
> > I once had a private copy of the source som
On Sunday 01 December 2002 17:06, Miguel Howard wrote:
> I am having some problems that I do not understand. It has something to do
> with the classpath.
The manifest file of a jar states which other jars should be added
to the classpatch... which enables one to do java -jar jmol.jar
See: src/man
The development version of Jmol has a problem on Mac OS X 10.2 jaguar.
There appears to be a bug in the jvm implementation which causes a severe
crash in the midst of Graphics2D operations. In Jmol, it only shows up
when displaying shaded atoms.
It crashes and put
Abort trap
on the console. All
> I will extract it from the Sun 3DAPI distribution. And will put that
> info in the commit message
I am having some problems that I do not understand. It has something to do
with the classpath.
- I successfully downloaded the sun distribution
- vecmath.jar is a separate file
- I moved it to th
> Is it actually maintained somewhere?
vecmath.jar is now included as a standard part of the Java3D API.
> I once had a private copy of the source somewhere to be used in CDK, or
> Jmol, or something else... but I cannot find it anymore...
I would love to take a look at the source. Let me know if
On Sunday 01 December 2002 15:42, mth wrote:
> Do you think it would be easy/possible to move to a newer version of the
> javax.vecmath package?
Is it actually maintained somewhere?
I once had a private copy of the source somewhere to be used in CDK, or Jmol,
or something else... but I cannot fi
Egon,
Do you think it would be easy/possible to move to a newer version of the
javax.vecmath package?
I think it would be useful to use the Point3i class to represent screen
coordinates. It is not available in the older version of javax.vecmath
which we are using.
Miguel
---
Hi all,
I've been changing the way CDK is compiled. The current build.xml will have
compile-* and dist-* task for each module, and these tasks will take care that
dependencies are fullfilled.
Moreover, a second change is made: CDK is no longer compiled from the Java
source files in ${src}, but
>> I assume that moving to CDK is a good thing.
I intended that to be a statement, not a question.
But thanks for enumerating the advantages for me.
>
> Yes, it is ;)
> The advantages:
>
> 1. CDK has a larger developers community
> 2. CDK has a large repository of chemoinformatical libraries
>
On Sunday 01 December 2002 13:41, mth wrote:
> > Mmm... that is precisely what I did... I'll look and see why it does not
> > work...
> > ...
> > If I can't find the problem, I'll do a fresh co too...
>
> I assume that you were able to compile from scratch?
No. Did an update -Pd again, and now it
On Sunday 01 December 2002 13:38, mth wrote:
> >> Q: What was the reasoning behind using doubles instead of floats? Is
> >> it the case that this level of precision (or range) is needed?
>
> Is there any type of calculation in chemistry where it would ever make
> sense to have that much range & pre
> Mmm... that is precisely what I did... I'll look and see why it does not
> work...
> ...
> If I can't find the problem, I'll do a fresh co too...
>
I assume that you were able to compile from scratch?
Miguel
---
This sf.net email is sponso
>> Q: What was the reasoning behind using doubles instead of floats? Is
>> it the case that this level of precision (or range) is needed?
Is there any type of calculation in chemistry where it would ever make
sense to have that much range & precision?
> I did not report it yet, as I was wondering
On Sunday 01 December 2002 11:31, Fabian Dortu wrote:
> On Sat, 2002-11-30 at 20:32, mth wrote:
> > I just checked in a version of the code which adds two interesting items
> > to the View menu (temporarily).
> > - Double Buffering
> >This allows you to turn on/off double buffering under javax
On Sunday 01 December 2002 12:52, mth wrote:
> As part of the conversion to the cdk Atom class I noticed that the
> physical coordinate representation of atoms (in Angstroms) went from float
> -> double ... Point3f -> Point3d.
>
> It really doesn't matter to me. And remember that I am not a chemist
On Saturday 30 November 2002 09:44, mth wrote:
> > you last commit gives a compile problem:
>
> I changed the parameter signatures on several existing methods.
> I think you just need to do a full recompile
> ant clean
> ant
Mmm... that is precisely what I did... I'll look and see why it does
As part of the conversion to the cdk Atom class I noticed that the
physical coordinate representation of atoms (in Angstroms) went from float
-> double ... Point3f -> Point3d.
It really doesn't matter to me. And remember that I am not a chemist ...
Q: What was the reasoning behind using doubles i
>> Great! No more flickering with double buffering!
> Very good. I'll commit the change shortly. I hope that it solves Egon's
> flickering too ...
I just checked in a version which uses double-buffering by default.
For the time being I left the setting under View -> Double Buffer
Miguel
-
>>NOTE: Please let me know if you do *not* like this transluscent
>> rendering and I will put a checkbox in the color options.
> I like it.
Good.
>>NOTE: Please let me know if you really want the "n atoms selected"
>> status message and I will reimplement it.
> Yes, I thi
> Great! No more flickering with double buffering!
Very good. I'll commit the change shortly. I hope that it solves Egon's
flickering too ...
> I did not notice any
> appreciable change in speed whatever Graphics2D or double buffering is
> on or off.
OK
> With Graphics2D, the quality is much bett
Egon,
In the course of testing before checking I observed that
samples/estron.cml is writing error messages to the jmol console.
I suspect that it is part of the conversion to the cdk base classes, so
you are probably already be aware of the issue.
The messages are:
Not adding charge for atom
On Sat, 2002-11-30 at 23:20, mth wrote:
> I made changes to the selected (picked) atoms. Visible changes are:
> - Halo is now transluscent on Graphics2D platforms, so you can see
>the bonds and atoms through the halo. You can test it out by
>toggling View -> Use Graphics2D
>NOTE: Pleas
On Sat, 2002-11-30 at 20:32, mth wrote:
> I just checked in a version of the code which adds two interesting items
> to the View menu (temporarily).
> - Double Buffering
>This allows you to turn on/off double buffering under javax.swing.
>!!NOTE!! Try this out and see if it eliminates your
It is now the case that the bond widths get smaller as you zoom away.
I have noticed an undesirable rather abrupt change in width as the bond
widths get small.
I'll take a look at it later and try to fix it.
Miguel
---
This sf.net email is
26 matches
Mail list logo
