Recent changes to patches

NumberRangeModel setValueRange() for double values

Alex — Fri, 16 Oct 2009 12:45:39 -0000

When you work with a NumberRangeModel that is initialized with double values, setting the value range with the method setValueRange() yields an unexpected result (a tiny range close to the minimum is selected).

The bug is in updateRange(), where the double range is transformed to an int range from 0 to 10,000.
The problem is that the multiplication with 10,000 happens *after* the intermediate result is converted to int.
So, v and e are either 0 or 10,000.

The same bug and patch should apply to NumberRangeModel that are initialized with long values. (I did not test it.)

NumberRangeModel that are initialized with int values are not affected by this issue, because they do not need such an transformation.

Bug: graph edges not connected with nodes

Alexey Ivanov — Fri, 02 Oct 2009 12:08:25 -0000

When FlareVis inside a canvas sometime edges not moving with nodes (not connected)
This problem solving by one line:

In the class 'flare.animate.Tween' see function step():

internal override function step(ef:Number):void
{
// run the interpolators
for each (var i:Interpolator in _interps) {
i.interpolate(ef);
}
DirtySprite.renderDirty(); // ADD ME TO SOLVE THIS BUG
}

Don't show empty tooltip with multiple fields

Alex — Fri, 07 Aug 2009 08:34:28 -0000

If ToolTipControl is activated for a VisualItem, which has other fields than the ToolTipControl, it won't have any text to display in the tooltip. Therefore, it should not even show the tooltip.

For a ToolTipControl that is configured with a single field, this already works in prefuse beta-20071021.
My patch makes a ToolTipControl with multiple field work correctly.

TypeLib.getNumericType bug

Anonymous — Sun, 10 May 2009 14:36:12 -0000

I found a bug in prefuse.util.TypeLib concerning a check it does on its parameters. Described here: http://sourceforge.net/forum/forum.php?thread_id=3269051&forum_id=343013

Flare: AxisLayout - setting preferredMin/Max when stacking

golgo32 — Sun, 02 Nov 2008 19:35:29 -0000

Currently, setting AxisLayout::x/yScale::preferredMin/Max has no effect when AxisLayout::x/yStacked = true. To fix the problem, comment out the following lines from the end of AxisLayout.as. Note: I haven't observed any unintended side effects of this patch, but that doesn't mean there aren't any!

if (_xStacks) {
_xBinding.scaleType = ScaleType.LINEAR;
// _xBinding.preferredMin = 0;
// _xBinding.preferredMax = xmax;
}
if (_yStacks) {
_yBinding.scaleType = ScaleType.LINEAR;
// _yBinding.preferredMin = 0;
// _yBinding.preferredMax = ymax;
}

Memory leak patch

(ode_m0nkey — Wed, 21 May 2008 22:53:15 -0000

Attached is a patch to address a memory leak issue I was having. The problem is that ExpressionListeners were getting added to the VisiblePredicate constants and never cleaned up. My solution was to override addExpressionListener(...) in the TRUE and FALSE convenience instances to do nothing (since they are constant, there should never be a change and therefor ExpressionListeners will never need to be notified).

To accomplish this I had to make AbstractExpression.addExpressionListener(...) non final.

Please chime in if this is not the correct solution.

(ode_m0nkey

Increase ActivityManager stack depth

Trejkaz — Thu, 24 Jan 2008 00:37:00 -0000

The default stack depth for the JVM (256kB) will only allow for just over 2000 nodes in a graph before the NBodyForce causes a StackOverflowError.

This patch increases that limit to 1MB just for the ActivityManager thread, to allow for presumably 2000^4 (larger than Integer.MAX_VALUE anyway.) It does use an API call in Java 1.4 though, and I wasn't sure if Prefuse was maintaining compatibility for any versions older than that.

You can get a similar effect by using the -Xss1M parameter to the JVM, but that would increase the size of all threads, which will penalise you if you have a large number of threads.

Display.pan fix

Trejkaz — Thu, 09 Aug 2007 01:11:33 -0000

Fix for Bug 1770531.
http://sourceforge.net/tracker/index.php?func=detail&aid=1770531&group_id=98962&atid=622645

Patch so TreeMLWriter does not write out null attributes.

Micah — Mon, 23 Jul 2007 14:06:42 -0000

TreeML defines attributes that each node in the tree can choose to implement. When TreeMLReader reads in a node which doesn't implement a certain attribute, it places a null object in the row of that attribute's column. However, When TreeMLWriter writes a graph that contains a null attribute, it introduces the attribute to the node and assigns its value to the string "null". This means that writing in and immediately writing out a TreeML file adds in a bunch of new attribute tags that were previously not there. I don't know whether or not this behavior is intentional, but it can be fixed by changing the line...

xml.tag(Tokens.ATTR, attr, vals, 2);

to...

if (vals[1] != null) {
xml.tag(Tokens.ATTR, attr, vals, 2);
}

Patch so TreeMLWriter does not write out null attributes.

Micah — Fri, 20 Jul 2007 16:50:24 -0000

xml.tag(Tokens.ATTR, attr, vals, 2);

to...

if (vals[1] != null) {
xml.tag(Tokens.ATTR, attr, vals, 2);
}