Skip to main content

Spring.max

6 replies [Last post]
mthornton
Offline
Joined: 2003-06-10

Anyone know why the setValue method has been implemented in the way that it has? (See bug 4779001).

P.S. is there anyone else here?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
milnep
Offline
Joined: 2003-11-02

> > P.S. is there anyone else here?
>
> I'm here, but can't say much about the SpringLayout
> and its design goals.
>
> As long as there's no tool support for the
> SpringLayout, I consider this powerful layout manager
> quite useless.

Here are a couple of design tools which have WYSIWYG support
for SpringLayout and its Springs:

http://bob.twistedprotein.com

and

http://java.sun.com/products/javabeans/beanbuilder/

One other point that may be of interest: the above
tools are compatible with each other. Because they both
use 1.4's new XMLEncoder/XMLDecoder to save and load designs,
you can create a user interface in one tool - save it as
XML and then work on it in the other tool. So, a bit
like HTML, your user interface is not tied to the tool
you created it with.

Philip

milnep
Offline
Joined: 2003-11-02

> Anyone know why the setValue method has been
> implemented in the way that it has? (See bug
> 4779001).

Sorry Mark, to answer your original question...

Say we create a maximum spring as follows:

Spring s3 = Spring.max(s1, s2);

the implicit contract of the method that creates s3
is that the spring, s3, should always satisfy:

s3.getValue()= Math.max(s1.getValue(), s2.getValue())

The same formulae holding for s3's: minimum, preferred,
and maximum properties. [BoxLayout uses a similar
specification to define the width characteristics of
a vertical box - in a spec. that really has its
origin in Knuth's TeX.]

This much seems pretty uncontentious. Unfortunately,
its not enough to determine exactly what should happen
when setting the value, as in:

s3.setValue(100)

... because s1 and s2 could take many values that would
have a maximum of 100. What the Spring.max() implementation
does is to choose the solution, satisfying the above, which
is closest to the preferred values of springs s1 and s2.
I.e. it gets the right answer by stretching or compressing
springs s1 and s2 as little as possible. That was the
intention of the existing implementation anyway.

I've always been worried that this was arbitrary
(and possibly wrong) but the implementation suggested
in the bug report seems a bit arbitrary to me too.
I couldn't immediately see why the suggested imlementation
was better than the existing one but I have a feeling I'm
missing something...

mthornton
Offline
Joined: 2003-06-10

Thanks Philip. In practice the current implementation seems to work well in the cases I've tried so far, but it is nice to know the reasoning behind an apparently arbitrary choice.

milnep
Offline
Joined: 2003-11-02

... I was missing something! There is another solution
which seems like the "right" answer to me (today). Its
this:

public void setValue(int size) {
super.setValue(size);
if (size == UNSET) {
return;
}
double strain = getStrain();
s1.setStrain(strain);
s2.setStrain(strain);
}

I've added this as a suggestion in the bug report:

http://developer.java.sun.com/developer/bugParade/bugs/4779001.html

The Spring.max operator was a special case from the rest of
the operators in the Spring class. This implementation stops
the max operator being a special case and allows some nice
properties of individual springs to apply to entire spring
layouts.

karsten
Offline
Joined: 2003-06-11

> P.S. is there anyone else here?

I'm here, but can't say much about the SpringLayout and its design goals.

As long as there's no tool support for the SpringLayout, I consider this powerful layout manager quite useless.

mthornton
Offline
Joined: 2003-06-10

> As long as there's no tool support for the
> SpringLayout, I consider this powerful layout manager
> quite useless.

I'm working on something, if only to learn what SpringLayout can do.