scaleFactor strangeness

[hh]

@Mark

> this proposal is identical to anything which offers the ability to set
> a transform on any object and so still suffers from it.

Not really, if you mean affine transform. Translation destroys the wonderful
commutativity you have with my proposal: If you interchange objects in the
owner path/message path before a target then this has no effect on the total
scalefactor of this target. And you know the "inverse" operation as a function!
Beside the usual rounding effects I can see no problem with that at the moment.

But I see your (good) arguments related to stack's scalefactor.
Mine are to see it hierarchically in the top level:

The stack (and it's view) is the global object and handles with the OS and
the hardware (you have a lot of pretty things already realized for us).
Everything in the stack is in local coords.

The mouseLoc etc. is scaled by TSF(mouse) = SF(stack)*SF(card)*SF(mouse).
We don't have to care about such things, you do in the engine.
And it is scripter's problem to ask for the total scalefactor ('TSF') of objects.

For example one may set SF(mouse)=1/SF(stack)/SF(card) to have TSF(mouse)=1, the
usual unscaled local coords (which are then correct physical coords, relative to
physical coords of the topleft of the window).

> We already have the 'fullScreenMode' property - which controls the 
> transform from 'card-space' to 'window-space'.

This is for me still the card space, everything on the card has its old coordinates
now multiplied by a different SF(stack) and is clipped to the screenrect.

> So if your stack is 400x400 and you want to display the middle portion 
> (100,100,300,300); then you'd set something like:
> set the visibleRect of stack ... to "100,100,300,300"
> This would scale and translate the 200x200 middle rectangle to fill the 
> entire window.

This is for me a change of the card's scalefactor with an unchanged stack's
scalefactor: For each and every object
             TSF(object) = SF(stack)*SF(card)*SF(object)
has changed its second factor.
This means, in that situation of a window that clips the stack, you could once
again zoom in/out by simply changing the card's scalefactor (and clipping) and
leaving the topleft of the clipping window pinned to screen.
No need to change global coords.

This example could be essentially a starting point for the discussion. One stays
on the same hardware, leaves SF(stack) unchanged. Then changing SF(card) would
leave the topleft of stack's window unchanged and scale everything on the card
(incl. mouseLoc).
[Additionally changing the width and height of stack's view or clipping to
another/the old size could be an option.]

If I'm right, has every object beside (sub-)stacks currently the owner "card",
so that the owner paths of a mainstack seem to lead uniquely to:
         TSF(stack) = SF(stack)
          TSF(card) = SF(stack)*SF(card)
        TSF(object) = SF(stack)*SF(card)*SF(object)

TMHO, this is isn't more complicated and burden with problems than the handling
of a property like "colour".
Anyway, thanks and praise to the whole team for some really great (even though partly unfinished) improvements of LC.