scaleFactor strangeness

[Mark Waddingham]

On 2015-10-14 00:38, Richard Gaskin wrote:
> Marty Knapp wrote:
>> It would nice to see this developed more for sure. At this point, I'd
>> settle for something even quasi - elegant, just for my users to be 
>> able
>> to have a magnified view of the screen.
> 
> FWIW, for folks making productivity apps in which scaling a group
> would be useful:
> 
> Can we have the scalingFactor available for the contents of groups?
> <http://quality.runrev.com/show_bug.cgi?id=11842>

This would indeed be nice (and, indeed, it has come up many times 
before) - however there are two problems.

The first is that all co-ordinates from a script point of view in the 
engine are integers, rather than floating point. This becomes important 
when you are starting to talk about transformations - for example 
scaling down an object of width 9 by a factor of 2 means the object's 
width is 4.5. So in this scenario the rect of an object within a scaled 
group would be inaccurate with how things are currently.

The second is that the current script's co-ordinate model is such that 
all co-ordinates are relative to the top-left of the current card rather 
than the owning group.

Now, the first can probably be ignored if the second is solved and 
co-ordinates are always expressed relative to the containing groups 
co-ordinate system (i.e. if you put a 10x10 button at 10,10 inside a 
group which scales things down by half, then the buttons rect would be 
10,10,20,20 but it would appear at 5,5,10,10 on the card). However, I'm 
not sure how that squares up with script's idea of what co-ordinates 
should be relative to from a script point of view - we've all got very 
used to a single flat co-ordinate system which means there's no need for 
transforming between 'co-ordinates relative to one object' to 
'co-ordinates relative to another object'.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps