> I've been testing the samples/ files with the CVS version... then I
> realized that I could live with the problem in the next release, *if*
> loading a new file would reset the screen coordinates... now the become
> zero at a yet unknown event, and then stay zero... if they would be
> reset to
On Monday 28 October 2002 22:03, mth wrote:
> > Miguel, what would be the best way to nail this basterd?
>
> I will try to reproduce the problem tomorrow on a Mac G3.
>
> If I can't reproduce it, then I recommend that I back the changes out of
> cvs. Then I will reintroduce them in smaller steps. I
> Miguel, what would be the best way to nail this basterd?
I will try to reproduce the problem tomorrow on a Mac G3.
If I can't reproduce it, then I recommend that I back the changes out of
cvs. Then I will reintroduce them in smaller steps. I think that is the
easiest way to find them. Egon, I'v
On Monday 28 October 2002 21:08, Fabian Dortu wrote:
> On Mon, 2002-10-28 at 18:40, Egon Willighagen wrote:
> > On Monday 28 October 2002 18:06, Fabian Dortu wrote:
> > > On Mon, 2002-10-28 at 11:04, Egon Willighagen wrote:
> > > 3. the crystal window is often marked available (menu item not
>
On Mon, 2002-10-28 at 18:40, Egon Willighagen wrote:
> On Monday 28 October 2002 18:06, Fabian Dortu wrote:
> > On Mon, 2002-10-28 at 11:04, Egon Willighagen wrote:
> > 3. the crystal window is often marked available (menu item not grey)
> > when file does not support crystal data (Fabian)
> >
On Mon, 2002-10-28 at 18:43, Egon Willighagen wrote:
> On Monday 28 October 2002 18:51, Fabian Dortu wrote:
> > I am able to reproduce it whathever the sample file (I didn't test all
> > of them, I confess) with the new version on a debian stable(woody) P3
> > 450Mhz with an exported display (don't
On Monday 28 October 2002 18:51, Fabian Dortu wrote:
> I am able to reproduce it whathever the sample file (I didn't test all
> of them, I confess) with the new version on a debian stable(woody) P3
> 450Mhz with an exported display (don't know if it is important): the
> atoms seem to collapse in th
On Monday 28 October 2002 18:06, Fabian Dortu wrote:
> On Mon, 2002-10-28 at 11:04, Egon Willighagen wrote:
> 3. the crystal window is often marked available (menu item not grey)
> when file does not support crystal data (Fabian)
>
> Actually, this issue was already discussed when I sent the cr
On Monday 28 October 2002 11:04, Egon Willighagen wrote:
> there are enough changes to justify a new release. There are however a few
> outstanding issues that need to be solved before the release:
>
> 1. it should be checked wether all strings in Jmol are internationalized
> (i.e. making use o
Hi all,
I want to drop the use of the Jmol Console for outputing information.
Debugging output will be saved to file (jmol.log), and informative messages
should end up in the status bar... Are there developers that still use the
Jmol Console for any use? Please let me know, before I remove it...
I am able to reproduce it whathever the sample file (I didn't test all
of them, I confess) with the new version on a debian stable(woody) P3
450Mhz with an exported display (don't know if it is important): the
atoms seem to collapse in the upper left corner. If a new file is open,
the atoms stay co
>> 2. a displaying bug in the performance patch when doing (faster)
>> rotation
>> with "wire frame rotation" (Miguel)
>
> I had already this kind of problem with the previous version on a Debian
> Sid (unstable) and after rotating for some time, the JVM crashed. But
> this was Debian unstable
Sorry, my last message was badly formatted.
On Mon, 2002-10-28 at 11:04, Egon Willighagen wrote:
>
> Hi all,
>
> there are enough changes to justify a new release. There are however a few
> outstanding issues that need to be solved before the release:
>
> 1. it should be checked wether all stri
On Mon, 2002-10-28 at 11:04, Egon Willighagen wrote:
Hi all,
there are enough changes to justify a new release. There are however a few
outstanding issues that need to be solved before the release:
1. it should be checked wether all strings in Jmol are internationalized
On Monday 28 October 2002 11:21, mth wrote:
> > I've found a bug. When looking at samples/dna.xyz, choosing
> > Display->Wire Frame Rotation, I get this:
>
> > Could you please have a look at this? It might be difficult, as it seems
> > to be a timing issue, which is harder to locate on faster ma
Hi all,
there are enough changes to justify a new release. There are however a few
outstanding issues that need to be solved before the release:
1. it should be checked wether all strings in Jmol are internationalized
(i.e. making use of translate()...) (Egon)
2. a displaying bug in the perf
> I've found a bug. When looking at samples/dna.xyz, choosing
> Display->Wire Frame Rotation, I get this:
>
...
> Could you please have a look at this? It might be difficult, as it seems
> to be a timing issue, which is harder to locate on faster machines... I
> use a Pentium II, 300 Mhz.
>
Eg
Hi all,
now being the new Jmol project leader, I want to define some goals the project
wants to achieve in the next period.
A bit of history:
Jmol was developed out of needs of Dan Gezelter. Xmol which he used to use did
not meet his requirements, and thus wrote a better tool: Jmol. This is c
On Sunday 27 October 2002 22:34, mth wrote:
> I checked in some changes which improve redisplay/rotation performance.
> Basic approach is to use integer variables for screen coordinates instead
> of Point3f objects. This allows operations without generating/discarding
> objects.
> Should be no visi
19 matches
Mail list logo
