pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: Square PushButton
Date Wed, 12 Aug 2009 00:37:14 GMT
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>
>>
>


Mime
View raw message