In Javascript land, if the weights don't add up to exactly 100 then you get weird positioning behaviour, and no warnings or errors as to why.

This small patch fixes that and allows any relative weight sizes, just like Java does! The fix is simple, where before the sizes were divided by 100, they're now divided by the sum of the weights.

diff -r a77e9070251b src/fwt/js/SashPanePeer.js
--- a/src/fwt/js/SashPanePeer.js Fri Sep 04 09:11:51 2015 -0400
+++ b/src/fwt/js/SashPanePeer.js Thu Sep 10 00:35:26 2015 +0100
@@ -55,9 +55,10 @@
fan.fwt.SashPanePeer.prototype.doVert = function(self)
{
- var w = this.m_size.m_w;
- var h = this.m_size.m_h;
- var wt = this.m_weights;
+ var w = this.m_size.m_w;
+ var h = this.m_size.m_h;
+ var wt = this.m_weights;
+ var sum = wt==null ? null : wt.m_values.reduce(function(a, b) { return a + b }, 0);
var dy = 0;
var dh = Math.floor(h /self.m_kids.size());
@@ -65,7 +66,7 @@
for (var i=0; i<self.m_kids.size(); i++)
{
var cw = w;
- var ch = wt==null ? dh : Math.floor(h * (wt.get(i).valueOf() / 100));
+ var ch = wt==null ? dh : Math.floor(h * (wt.get(i).valueOf() / sum));
// if last widget, force to fill remaining space
if (i == self.m_kids.size()-1) ch = h-dy;
@@ -79,16 +80,17 @@
fan.fwt.SashPanePeer.prototype.doHoriz = function(self)
{
- var w = this.m_size.m_w;
- var h = this.m_size.m_h;
- var wt = this.m_weights;
+ var w = this.m_size.m_w;
+ var h = this.m_size.m_h;
+ var wt = this.m_weights;
+ var sum = wt==null ? null : wt.m_values.reduce(function(a, b) { return a + b }, 0);
var dx = 0;
var dw = Math.floor(w / self.m_kids.size());
for (var i=0; i<self.m_kids.size(); i++)
{
- var cw = wt==null ? dw : Math.floor(w * (wt.get(i).valueOf() / 100));
+ var cw = wt==null ? dw : Math.floor(w * (wt.get(i).valueOf() / sum));
var ch = h;
// if last widget, force to fill remaining space

andyWed 9 Sep 2015

I think thats more a bug in SWT implementation - would make it consistent to add up to 100% (and clip/append last child to make up the difference).

SlimerDudeThu 10 Sep 2015

thats more a bug in SWT implementation

I'm not convinced - from using other GUIs, that's exactly how I imagined it to work - plenty of SWT Sash examples back me up too:

flex-grow: Accepts a unitless value that serves as a proportion. It dictates what amount of the available space inside the flex container the item should take up.

If all items have flex-grow set to 1, every child will set to an equal size inside the container. If you were to give one of the children a value of 2, that child would take up twice as much space as the others.

## SlimerDude Wed 9 Sep 2015

I know the docs for

`weights`

in a`SashPane`

say:But in Java land the weight numbers are actually arbitrary, and the numbers are just used to denote relative sizing. Hence the following are the same:

In Javascript land, if the weights don't add up to exactly 100 then you get weird positioning behaviour, and no warnings or errors as to why.

This small patch fixes that and allows any relative weight sizes, just like Java does! The fix is simple, where before the sizes were divided by 100, they're now divided by the sum of the weights.

## andy Wed 9 Sep 2015

I think thats more a bug in SWT implementation - would make it consistent to add up to 100% (and clip/append last child to make up the difference).

## SlimerDude Thu 10 Sep 2015

I'm not convinced - from using other GUIs, that's exactly how I imagined it to work - plenty of SWT Sash examples back me up too:

## SlimerDude Mon 5 Oct 2015

Just realised my bias could be because I'm used to CSS Flex Boxes:

From CSS-Tricks - A Complete Guide to Flexbox: