Mailing lists are slow right now...
The latest code in SVN appears to produce the results I think you are
looking for. I modified your example to use the current style name and
value definition. When I run it, I see a UI containing three buttons,
all of which appear to have an aspect ratio of 1.2. Please let me know
if you see otherwise.
Thanks,
G
On Aug 11, 2009, at 8:17 PM, Greg Brown wrote:
This message didn't seem to go through the first time...hopefully it
will this time.
On Aug 11, 2009, at 8:03 PM, Greg Brown wrote:
Scott,
Try syncing with the latest from SVN, and change
minimumPreferredAspectRatio back to preferredAspectRatio and -1.2
to 1.2. Please let me know how that works.
Thanks,
G
On Aug 11, 2009, at 6:20 PM, Scott Lanham wrote:
Attached is the most recent wtkx file I have been testing with.
On Tue, 11 Aug 2009 10:39:12 pm Greg Brown wrote:
This is actually almost identical to how it used to work before I
renamed the property to minimumPreferredAspectRatio, so I guess it
probably makes sense to revert that.
However, due to a caching issue, you still won't quite be able to
achieve what you are trying to do. We currently cache the values of
the preferred size calculations for performance reasons. So, the
widest component doesn't get scaled up (nor do any other components
that report the same preferred width). I have a fix in mind, but I
want to give it some thought before committing it. I'll make the
changes to TerraPushButtonSkin, anyways and the cache fix will come
later.
On Aug 10, 2009, at 9:56 PM, Scott Lanham wrote:
From what I can see the way the current aspect ratio is calculated
and then
used is biased towards an increase in width. In that context I can
see why you
call it a minimum aspect ratio.
To make what I want work I need the bias to be for the height to
increase so
that really the aspect ratio is a maximum. So what I have done
is to
say that
if the aspect ratio is +ve then the current behaviour applies
but if
it is -ve
then the aspect ratio is a maximum and the height needs to be
increased. Using
a negative number has just been a simple way of getting a result
without
having to change to much code.
---
In getPreferredWidth() nothing changes.
In getPrefereedHeight() the calculation using aspect ratio is:
// Adjust for preferred aspect ratio
if (!Float.isNaN(minimumPreferredAspectRatio)
&& minimumPreferredAspectRatio < 0.0
&& (float)width / (float)preferredHeight > -
minimumPreferredAspectRatio) {
preferredHeight = (int)(width / -
minimumPreferredAspectRatio);
}
In getPreferredSize() it is:
// Adjust for preferred aspect ratio
if (!Float.isNaN(minimumPreferredAspectRatio)
&& (float)preferredWidth / (float)preferredHeight <
minimumPreferredAspectRatio) {
preferredWidth = (int)(preferredHeight *
minimumPreferredAspectRatio);
}
else if (!Float.isNaN(minimumPreferredAspectRatio)
&& minimumPreferredAspectRatio < 0.0
&& (float)preferredWidth / (float)preferredHeight > -
minimumPreferredAspectRatio) {
preferredHeight = (int)(preferredWidth / -
minimumPreferredAspectRatio);
}
---
The height not being changed when the aspect ratio is +ve doesn't
appear to
affect either of our use cases. I can't think what affect this
will
have in
general.
On Tue, 11 Aug 2009 10:04:26 am Greg Brown wrote:
OK. How about a high-level description of the change?
On Aug 10, 2009, at 6:31 PM, Scott Lanham wrote:
I'll give it a go but I will need to change what I have done.
It is
not
suitable to submit as a patch.
On Mon, 10 Aug 2009 10:38:34 pm Greg Brown wrote:
It is worth considering. Can you provide a patch that
implements
your
proposed solution so we can take a look?
<applicationUi.xml>
