Re: scaleFactor strangeness

[[-hh]]

[Sorry for the late answer, couldn't login to jasmine for a while.]

@Mark
Your explanations, quoted below, are so valuable that they should remain also 
readable for non-math people (that don't have a math-involved university 
degree).

So let us go back for a while from some general writing in transformation 
matrices to a simple real number. Also let us look only at the single 
(PROPORTIONAL) SCALEFACTOR, not split into a first-coord and second-coord one.

[Example 1]
> This handler would still function regardless of the transform of
> the graphic containing it. Indeed, if co-ordinates are delivered to
> it in the target object's local co-ordinate system - then it does.
> on mouseMove pX, pY
>if pX < item 1 of the loc of me then
>  if pY < item 2 of the loc of me then
>set the backColor of me to red
>  else
>set the backColor of me to green
>  end if
>else
>  if pY < item 2 of the loc of me then
>set the backColor of me to blue
>  else
>set the backColor of me to orange
>  end if
>end if
> end mouseMove

[Example 2]
> However, here is a handler which would not work fine in this instance:
> on mouseMove pX, pY
>if pY < the top of me + 20 then
>  set the backColor of me to red
>else if pY > the bottom of me - 20 then
>  set the backColor of me to green
>else
>  set the backColor of me to blue
>end if
> end mouseMove

For me there is no difference in coords between Examples 1 and 2.
If all coords are in card-space then absolute values (like 20) are too.
This is definable and should be defined this way.

If a user means 20 pixels in the object-space (although pX and the top of me 
are in card-space) then it can be adjusted:

if pY < the top of me + 20*SF(me)

If a scripter doesn't touch default scalefactors, then SF(me) of an object is 
one and has no scaling effect, similar with SF(the target).

I personally would prefer and use your general approach of affine transforms 
but the simple "scalefactor" of objects is easy to understand, also for 
beginners.
 
We have the total scalefactor for objects that are direct on card level:
TSF(object)=SF(stack)*SF(card)*SF(object)

If we now set SF(card)=1/SF(stack), then we have everything in usual local card 
coords, the display remains the same, but we can by emulating your usual 
adjusting of SF(stack) look at an emulated device display --- PMDE (poor man's 
device emulator).

>From your other considerations regarding 'loc', 'left', 'top', 'right', 
>'bottom', 'width' and 'height' I can see, that you are nearly done, you could 
>now write the (general transform) code right out of your brain. Let me repeat 
>in my words to see if I got it all and give one more definition. We have the 
>following kind of points:

* appPoints (x,y) = point on physical device = pixel (x,y)

Now define: the stack is owned by the application and
* relativePoint (x,y) = pixel (x,y) relative to the topleft of object
* ownerPoint (x,y) = pixel (x,y) relative to the topleft of object's owner

Of course: ownerPoints(object) = relativePoints(owner of object)

So, without scaling:
* ownerPoints(stack) = the app's coords (may tranform to other screen)
* ownerPoints(card) = the usual global coords
* ownerPoints(object on card) = the usual local coords
* ownerPoints(object in group) = relativePoints(group)

Now respect scalefactors:
* ownerPoints(stack) are handled by the engine only
* ownerPoints(card) = global coords scaled by TSF(stack)
* ownerPoints(object on card) = local coords scaled by TSF(card)
* ownerPoints(object in group) = local coords scaled by TSF(group)
* relativePoints(object in group) = local coords scaled by TSF(object)

here is TSF(object) = (SF of owners along owner path)*SF(object) 
and again ownerPoints(object in group) = relativePoints(group)

Most of scaling would be done down to the owner of an object only, I presume.
For example working within a group with relative group coords and then simply 
setting SF(group) would be very attractive. That's why I would miss ownerPoints.

What's new then?
A further property for each object.
And some simple transforms that respect the scalefactors along the owner path, 
and are affine transformations ;-)

object2group, object2card, card2stack, substack2stack
group2object, card2object, stack2card, stack2substack

> Of course there is a gulf between having an idea that might work and 
> implementing it in the engine - the lack of floating point co-ordinates 
> is going to be a huge issue here I think

One could work always with floating points? Then let the engine round, not 
before the very end of calculations, whenever an integer is needed?

> The 'visibleRect' of a stack  is at least feasible in the near term
> - which at least gives zoom and  panning at the card-level if not at
> the individual object level.

This is a great feature. And with this, apart from clipping to the stacks's 
window, we have already scalefactor(card) available, 

Re: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-15 19:42, hh wrote:
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.


I'm not sure I follow - commutativity makes no difference in this 
instance - you only need invertibility and associativity. Affine 
transforms can be represented as matrices and matrix multiplication is 
associative, and non-degenerate matrices have inverses - thus you can 
replace any scale operation in your proposal with an arbitrary 
(invertible) matrix representing an affine transform.


Indeed, in that light, what you propose is precisely the same as the 
idea of every object being able to have a transform property (if not set 
it is the identity) - the total transform of a nested object is the 
multiplication of all the ancestor transforms. This is how most UI 
toolkits (which allow arbitrary affine transforms) work and from a 
rendering point of view poses no problem.


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.


Yes - this is how it is at the moment - you can translate between local 
(card-relative) and global (screen-relative) using localLoc and 
globalLoc functions.


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.


Okay - so you suggest that any co-ordinates coming from the engine 
remain in card-space - where card-space is the top-level transform.


This does mean that script will have to explicitly deal with all 
co-ordinate transforms. So let's say you have a mouseMove handler in a 
graphic which uses the location of the mouse within itself to change its 
color:


on mouseMove pX, pY
  if pX < item 1 of the loc of me then
if pY < item 2 of the loc of me then
  set the backColor of me to red
else
  set the backColor of me to green
end if
  else
if pY < item 2 of the loc of me then
  set the backColor of me to blue
else
  set the backColor of me to orange
end if
  end if
end mouseMove

In an ideal world, this handler would still function regardless of the 
transform of the graphic containing it. Indeed, if co-ordinates are 
delivered to it in the target object's local co-ordinate system - then 
it does.


However, for arbitrary transforms where the pX, pY is kept in the card 
co-ordinate system it cannot - the reason for this is that under an 
arbitrary affine transform a rectangle which is parallel on both sides 
to the pixel grid may cease to be parallel to the pixel grid which means 
that geometry changes (when doing things extrinsically from the target 
object, at least).


Now, it is clear that if you restrict the transform to scale (and 
translation) then because such things preserve rectangles in both 
orientation and alignment relative to the pixel grid any non-size 
related geometry conditions you code remain correct - so the above 
handler would work fine.


However, here is a handler which would not work fine in this instance:

on mouseMove pX, pY
  if pY < the top of me + 20 then
set the backColor of me to red
  else if pY > the bottom of me - 20 then
set the backColor of me to green
  else
set the backColor of me to blue
  end if
end mouseMove

Under a 'keep everything at the card-space' model - this code breaks as 
the scale of the target object changes. This is because the handler is 
dependent on a size (20) which is relative to the object's innate size 
rather than its scaled size. So, for this handler to work (even in a 
restricted, scale/translate only transform model) the script would need 
to be amended:


on mouseMove pX, pY
  if pY < the top of me + 20 * the effective yScale of me then
set the backColor of me to red
  else if pY > the bottom of me - 20 * the effective xScale of me then
set the backColor of me to green
  else
set the backColor of me to blue
  end if
end mouseMove

Thus, in reality, keeping things in 'card-level' co-ordinate system and 
only allowing scale/translation makes no difference to the requirements 
on code. For general scripts which manipulate co-ordinates in anything 
other than very simple ways, you still have to explicitly take into 
account the potential effects of transformation thus, at the end of the 
day, you might as well allow arbitrary affine transforms since the code 
burden is identical. For example, the above modified code works if only 
scaling is allowing, however the code for the case of arbitrary 
transforms would be something 

Re: scaleFactor strangeness

[Monte Goulding]

Hmm... Even with the view object you would have an issue there. Inside the view 
they would be relative to the topleft of the view and in the coordinate system 
of the stack. If the message is passed it then becomes arguable whether the 
message hierarchy includes the stack the view is in and whether the parameters 
are altered to match the parent window (or maybe even parent view) coordinate 
system.

Can of worms...

Sent from my iPhone

> On 15 Oct 2015, at 7:38 pm, Mark Waddingham  wrote:
> 
> This is all well and good - however the part you haven't addressed is what 
> about co-ordinates that 'come into' the engine.
> e.g. mouseMove has pX, pY as parameters - what co-ordinate system are they in?

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Richard Gaskin]

Dr. Hawkins wrote:
> As far as retrofitting to the older language, as someone (Richard?)
> mentioned, it could be done by
>
>   set the groupTop of field myField to 100
>
> and so forth.

I don't think that one's mine, but similar ideas have been floating 
around for a while for making positioning within groups simpler.


I like the xOrigin and yOrigin in HTML's Canvas, and maybe something 
even simpler for LC groups might be a local property in the script along 
the lines of "the useGroupCoordinates" (maybe abbreviated 
"useGrpCoords"), e.g."


  set the useGrpCoords to the long id of grp "SomeParentGroup"
  set the rect of btn "ChildBtn" to 10,10,110,30

The result there would set the rect of the button "ChildBtn" relative to 
both the rect and scroll of the specified group.


Not married to the suggested token, but something like it might be a 
useful way of simplifying positioning within groups.


If scaling within groups were available, all scaling would be 
independent of our scripting.  That is, the script above would render 
appropriately whether the scale is 1, 0.5, or 2, so scripting works in 
factor 1 sizes while rendering accounts for the scale.


If we need to know the actual rects of objects within scaled groups, 
"the effective rect" would give us that info.


Scripts stay simple to write, coordinates obtainable either translated 
for scale or not with minimal effort.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-15 09:18, Richard Gaskin wrote:

Scripts stay simple to write, coordinates obtainable either translated
for scale or not with minimal effort.


This is all well and good - however the part you haven't addressed is 
what about co-ordinates that 'come into' the engine.
e.g. mouseMove has pX, pY as parameters - what co-ordinate system are 
they in?


Warmest Regards,

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-15 16:45, hh wrote:
The scalefactor SF of a button in a (non-background-) group on a card 
is then


SF(stack) * SF(card) * SF(group) * SF(button).


The problem I am concerned about is actually the differing co-ordinate 
systems at each level here and how that affects script - this proposal 
is identical to anything which offers the ability to set a transform on 
any object and so still suffers from it.



It's really simple, isn't it? And it works ...


Of course, posed as you have, it has made me realize that there is a 
potentially feasible option right now.


We already have the 'fullScreenMode' property - which controls the 
transform from 'card-space' to 'window-space'. This acts on the entire 
content of the card and thus doesn't have a problem with any translation 
of co-ordinate systems (as they don't change within the card).


What we didn't do was add the option of controlling this mapping 
directly and have the result displayed in a window. This could be done 
by adding a property which specifies the region of the card rect you 
want stretched to fill the window.


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.


The reason this is unaffected by my concerns about the action of script 
in such an environment is that script actions are contained entirely 
within the stack and objects within it. The co-ordinate transform 
boundary happens between the OS and the window essentially - which is at 
the globalLoc / localLoc level - the thing that changes is the mapping 
between what script considers to be 'card-relative' (local) and 
'screen-relative' (global). Script already has to take this into 
account, as does the engine (which it does, otherwise fullScreenMode 
wouldn't work).


Warmest Regards,

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[hh]

> The scalefactor SF of a button in a (non-background-) group on a card is then
> SF(stack) * SF(card) * SF(group) * SF(button).

Should read:

The 'total' scalefactor TSF of a button in a (non-background-) group on a card 
is then

TSF = SF(stack) * SF(card) * SF(group) * SF(button).



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[hh]

The scalefactor problem -- I reported this already months ago, in vain.

Currently LC uses the scalefactor as if the physical device has changed 
accordingly.
It scales(nearly) everything, and especially global coordinates.
That's why windows walk out to offscreen if you use a scalefactor > 1 and are 
still
staring at the same monitor.

Nothing bad about that, because

> "Use the scaleFactor property when developing to scale down stacks that 
> are larger than the available screen space."


What some of us wish is to use the scalefactor also for rendering (like PDF 
etc.).

For this a second kind of scalefactor is necessary. No way out of this.

** My proposal is to set a new property for all objects: the scalefactor **

The scalefactor of the stack remains the old one and may or may not used by its 
objects:
This scalefactor will be inherited (what obviously solves the group-problem).

The scalefactor of a button is then the product of the scalefactors of all the 
owners
along the owner path. That is, for example;

The scalefactor SF of a button in a (non-background-) group on a card is then

SF(stack) * SF(card) * SF(group) * SF(button).

Of course, the scalefactor of an object has the default value one.
The scalefactor of a stack is the only one that changes global coords. All 
others have
only impact on local coords.

For some few objects on a special stack I used this already by custom 
properties (that
is the math for all coords is to be computed, without difficulties, but its not 
native).

It's really simple, isn't it? And it works ...
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-15 11:08, Monte Goulding wrote:

Hmm... Even with the view object you would have an issue there. Inside
the view they would be relative to the topleft of the view and in the
coordinate system of the stack. If the message is passed it then
becomes arguable whether the message hierarchy includes the stack the
view is in and whether the parameters are altered to match the parent
window (or maybe even parent view) coordinate system.


Well the solution there is that the hosted stack's message path is *not* 
integrated into that of the host stack - the problem then goes away :)


Instead, think of a stackview control as creating a transformed space 
within a stack which is filled by another stack. It is a purely visual 
thing rather than structural.


Stacks can still communicate in all sorts of ways - for example, you 
could have substacks embedded in the mainstack so the messages flow in 
the current way you'd expect; or you could use a library which enables 
communication.


Also, there's also the option to add syntax allow a stack to send 
messages to its 'host' - whatever that might be. (This idea of 'host' 
isn't unique to the idea of stackview - exactly the same idea is present 
when you think about embedding a stack in a web-page in the HTML5 
engine).



Can of worms...


Only if you choose a worm-filled can ;)

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: 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.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-13 22:07, Scott Rossi wrote:

Many of us tried to do the same thing when the feature was first
announced.  Unfortunately, you can't really use it for a zoom effect, 
at
least not since I last looked into this.  As you've seen, the stack 
jumps
around as the scale is changed, and even if you reposition it 
dynamically,

the results aren't the best.


The 'scaleFactor' of a stack was implemented for a specific reason - as 
stated in the dictionary:


"Use the scaleFactor property when developing to scale down stacks that 
are larger than the available screen space."


It was neither intended as, nor designed to be used as, a general method 
for scaling stack content which is a somewhat different problem.


Warmest Regards,

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: 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?



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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Richard Gaskin]

Mark Waddingham wrote:

On 2015-10-14 00:38, Richard Gaskin wrote:

Can we have the scalingFactor available for the contents of groups?



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'.


Maybe those could be handled as the HTML Canvas does, in which the 
coordinates you use remain the same and the scale factor takes case of 
the translation for us when rendering.





Isn't that how Skia's canvas works also?

Workable for LC?

If we need to know the on-screen physical rect of a control (as distinct 
from its logical scaled rect) perhaps "the effective rect"?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Monte Goulding]

> On 14 Oct 2015, at 5:57 pm, Mark Waddingham  wrote:
> 
> 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.

Don’t both of these issues disappear if you create a stack view object instead 
of group scalefactor? Given a stack which already has a scaleFactor? Object 
rects remain relative to the stack whether the stack is presented as a window 
or in a view. From the perspective of the stack with the window it would just 
have a single view object which has a stackName and a rect.. perhaps some other 
stuff like visible etc...

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-14 09:46, Richard Gaskin wrote:

Maybe those could be handled as the HTML Canvas does, in which the
coordinates you use remain the same and the scale factor takes case of
the translation for us when rendering.


The problem is the mixture of co-ordinate systems on a card, if you have 
a scaled button in a group and an unscaled button outside of a group - 
how do coords work in an arbitrary script potentially unrelated to 
either?


If I'm sitting at the card level and I ask the scaled button for its 
rect, and the unscaled button for its rect, what do I get in each case?


If I'm sitting at the scaled button level and I ask the unscaled button 
for its rect, what do I get?


Let's say I want the button outside of the group to sit directly over 
the (scaled) button in the group. Right now, I would do:


  set the rect of button "Outside" to the rect of button "Inside"

However, in this newly imagined world where the 'inside' button is 
actually scaled and the 'outside' button is not, there's no clear 
agreement on what the 'rects' mean - should it become a matter of 
context of script? And, if so, is that always 100% well defined?. (This 
is even without taking into account the huge mathematical error which 
accumulates when you are restricted to rects being on an integer grid, 
and trying to take into account partly scaled and unscaled 
combinations).


The main thing which we need to avoid is the case where someone writing 
a 'reusable component' has to be aware of whether said component is 
sitting in a scaled group, compared to an unscaled group. If components 
have to be aware of this to function correctly, then it makes them a 
great deal more difficult to write.



Isn't that how Skia's canvas works also?


Yes - and how the graphics library we built on top of it works, and how 
the Canvas library used by LCB works.



Workable for LC?


Pretty much every single UI system since even before MetaCard appeared 
operated in a very standard way. Child controls were relative to their 
owning group.


MetaCard, I'm sorry to say, made a significant error of judgement (with 
hindsight of course) when implementing backgrounds and groups. 
Backgrounds should have been as HyperCard - full card things - i.e. 
layers which sat underneath the card. Groups should have been like every 
other toolkit which was out there at the time - a collection of controls 
whose rects were relative to the top-left of their owner (well, more 
exactly, relative to a co-ordinate system defined by the group).


The problem is that, 20 years on, our entire community is used to the 
way things are. All code is written to that standard and seeing how to 
move things into a model which the modern world considers the standard 
way of doing things without putting a line in the sand and saying 'we 
really have to break everything if you want to use this new feature' 
has, thus far, defeated me - sorry!


(By the way, working out how it might work from a script point of view 
is one thing; then of course you have to work out how the engine code 
can actually be moved forward to allow it).


Perhaps there is something simple and obvious which I'm missing, but I'm 
honestly not sure.


Warmest Regards,

Mark.


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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-14 11:01, Monte Goulding wrote:

That’s what I mean and if you present it somewhere else (different
window or view) then it moves and the previous view is emptied. If you
want two instances you clone the stack.


Yes - that would be the simplest way to do things (both technically, and 
from an actual use point of view).


I'll need to ponder where we are with the various 'abstractions' in the 
engine. The main problem is that MCStack has long been a hybrid 
window-stack - really, a 'stack' and a 'window' are two distinct 
concepts and I'm not sure they aren't entirely unentangled yet (Ian has 
worked on separating things out on and off for years - during the 
process of implementing High-DPI support and things like 
fullScreenMode).


Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Mark Waddingham]

On 2015-10-14 10:21, Monte Goulding wrote:

Don’t both of these issues disappear if you create a stack view object
instead of group scalefactor? Given a stack which already has a
scaleFactor? Object rects remain relative to the stack whether the
stack is presented as a window or in a view. From the perspective of
the stack with the window it would just have a single view object
which has a stackName and a rect.. perhaps some other stuff like
visible etc...


Yup - if you have a 'stackview' control - then the problem goes away 
because you have a nice clear dividing line between objects in one 
co-ordinate system compared to the other.


We'd probably want some explicit syntax for working out the rect of an 
object in a stackview, from the point of view of the stack containing 
the stackview; and also some means to communicate from the embedded 
stack to the host view... However, perhaps both of these things are 
unnecessary - the stacks could just as well communicate by sharing a 
common library.


Basically, there aren't really any difficult technical problems if you 
limit stackviews to being 'the ability to display a stack in a subpart 
of another stack, rather than a window' with no more integration beyond 
that, other than them being stacks.


Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Monte Goulding]

> On 14 Oct 2015, at 7:44 pm, Mark Waddingham  wrote:
> 
> Yup - if you have a 'stackview' control - then the problem goes away because 
> you have a nice clear dividing line between objects in one co-ordinate system 
> compared to the other.
> 
> We'd probably want some explicit syntax for working out the rect of an object 
> in a stackview, from the point of view of the stack containing the stackview; 
> and also some means to communicate from the embedded stack to the host 
> view... However, perhaps both of these things are unnecessary - the stacks 
> could just as well communicate by sharing a common library.

I don’t think the communication is necessary as we can communicate in the same 
ways we currently do between stacks. Some stack object coordinate -> coordinate 
system it is presented in translation would probably already be helpful.

> Basically, there aren't really any difficult technical problems if you limit 
> stackviews to being 'the ability to display a stack in a subpart of another 
> stack, rather than a window' with no more integration beyond that, other than 
> them being stacks.

That’s what I mean and if you present it somewhere else (different window or 
view) then it moves and the previous view is emptied. If you want two instances 
you clone the stack.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Richard Gaskin]

Mark Waddingham wrote:

On 2015-10-14 09:46, Richard Gaskin wrote:

Maybe those could be handled as the HTML Canvas does, in which the
coordinates you use remain the same and the scale factor takes case of
the translation for us when rendering.


The problem is the mixture of co-ordinate systems on a card, if you have
a scaled button in a group and an unscaled button outside of a group -
how do coords work in an arbitrary script potentially unrelated to
either?


How is that handled in HTML's Canvas?  Is the SVG Canvas any different?

I don't want to talk you out of adding the stack viewer object if that's 
easier to do (that's the one thing I miss from Gain Momenum), but given 
how HTML5 and SVG allow different scales for different objects I'd favor 
any solution that reduces learning time for folks familiar with those 
popular solutions.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Mark Waddingham]

The HTML5 canvas doesn't have that problem - canvas is just a render target you 
can use 2d vector drawing commands on - it doesn't have any notion of objects.

SVG and HTML's object model has always been children's coords are relative to 
the parent so you have to think about coordinate systems when you code 
(assuming you are using transforms of any kind and are passing points between 
related objects and are actually scripting anything that relies on coords).

The problem is that (ignoring coords being integers in LC at the moment - which 
is also a problem) all current scripts that exist assume coords are relative to 
the card - and I'm not sure there's a way to bridge those two things in a 
transparent / easy way.

It is the scripting part that is the potential issue, rather than the rendering 
part.

LiveCode's message path encourages you to factor out common code into 
ancestors, and as such might receive coordinates from any descendent - and this 
would complicate scripting in any such situation if transforms were involved 
somewhere between the origin of the coordinate and where that coordinate is 
handled.

Then again, perhaps that is okay - it's a necessary tax on the scripter for 
using that feature.

Hmm.

Mark.



Sent from my iPhone

> On 14 Oct 2015, at 21:12, Richard Gaskin  wrote:
> 
> Mark Waddingham wrote:
>>> On 2015-10-14 09:46, Richard Gaskin wrote:
>>> Maybe those could be handled as the HTML Canvas does, in which the
>>> coordinates you use remain the same and the scale factor takes case of
>>> the translation for us when rendering.
>> 
>> The problem is the mixture of co-ordinate systems on a card, if you have
>> a scaled button in a group and an unscaled button outside of a group -
>> how do coords work in an arbitrary script potentially unrelated to
>> either?
> 
> How is that handled in HTML's Canvas?  Is the SVG Canvas any different?
> 
> I don't want to talk you out of adding the stack viewer object if that's 
> easier to do (that's the one thing I miss from Gain Momenum), but given how 
> HTML5 and SVG allow different scales for different objects I'd favor any 
> solution that reduces learning time for folks familiar with those popular 
> solutions.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Monte Goulding]

> On 14 Oct 2015, at 8:07 pm, Mark Waddingham  wrote:
> 
> I'll need to ponder where we are with the various 'abstractions' in the 
> engine. The main problem is that MCStack has long been a hybrid window-stack 
> - really, a 'stack' and a 'window' are two distinct concepts and I'm not sure 
> they aren't entirely unentangled yet (Ian has worked on separating things out 
> on and off for years - during the process of implementing High-DPI support 
> and things like fullScreenMode).

Yeah, Im sure there would be lots to do. I think there’s lots of places that 
assume a stack is either open and has a window or not open or if it doesn’t 
have a window it needs one etc. Still an interesting idea and seemingly 
relatively feasible compared to messing with groups.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Dr. Hawkins]

On Tue, Oct 13, 2015 at 3:38 PM, Richard Gaskin 
wrote:

> Can we have the scalingFactor available for the contents of groups?
> 
>

That's probably the biggest single thing I cold wish for right now.  I'd
even call it a critical need . . .

I have scaling sort of working.  Not quite as well from drag-resizing, but
I have cmd-plus & -minus doing resizing--but I haven't been able to figure
out the math, so it does on walkabout as I hit these.

As far as retrofitting to the older language, as someone (Richard?)
mentioned, it could be done by

  set the groupTop of field myField to 100

and so forth.

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Scott Rossi]

Many of us tried to do the same thing when the feature was first
announced.  Unfortunately, you can't really use it for a zoom effect, at
least not since I last looked into this.  As you've seen, the stack jumps
around as the scale is changed, and even if you reposition it dynamically,
the results aren't the best.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/13/15, 12:57 PM, "use-livecode on behalf of Marty Knapp"
 wrote:

>I'm playing around with scaleFactor on a desktop app as sort of a "zoom
>view" feature. But there are some weirdnesses about it, especially in
>terms of screen placement. For example, when the scaleFactor is anything
>but 1, setting the loc of a stack is way off. Like setting the loc of a
>stack to the screenLoc does not place it at the center of the screen.
>
>It would be nice to be able to scale a window in/out from the topLeft or
>from the center of the stack too.
>
>I tried a few things, but nothing I came up with was very acceptable.
>Anybody else played with this?
>
>Marty K
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Devin Asay]

> On Oct 13, 2015, at 1:57 PM, Marty Knapp  wrote:
> 
> I'm playing around with scaleFactor on a desktop app as sort of a "zoom view" 
> feature. But there are some weirdnesses about it, especially in terms of 
> screen placement. For example, when the scaleFactor is anything but 1, 
> setting the loc of a stack is way off. Like setting the loc of a stack to the 
> screenLoc does not place it at the center of the screen.
> 
> It would be nice to be able to scale a window in/out from the topLeft or from 
> the center of the stack too.
> 
> I tried a few things, but nothing I came up with was very acceptable. Anybody 
> else played with this?

Marty,

Is what you’re seeing anything like I wrote in this bug report: 
http://quality.runrev.com/show_bug.cgi?id=13883

I included a screen capture of what was happening. If your issue seems like the 
same thing, leave a comment on the bug report. It would be nice if the mother 
ship could tighten this feature up a bit. 

Regards,

Devin

Devin Asay
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Marty Knapp]

Hey Scott,
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.


Marty

Many of us tried to do the same thing when the feature was first
announced.  Unfortunately, you can't really use it for a zoom effect, at
least not since I last looked into this.  As you've seen, the stack jumps
around as the scale is changed, and even if you reposition it dynamically,
the results aren't the best.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/13/15, 12:57 PM, "use-livecode on behalf of Marty Knapp"
 wrote:


I'm playing around with scaleFactor on a desktop app as sort of a "zoom
view" feature. But there are some weirdnesses about it, especially in
terms of screen placement. For example, when the scaleFactor is anything
but 1, setting the loc of a stack is way off. Like setting the loc of a
stack to the screenLoc does not place it at the center of the screen.

It would be nice to be able to scale a window in/out from the topLeft or

>from the center of the stack too.

I tried a few things, but nothing I came up with was very acceptable.
Anybody else played with this?

Marty K

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



--
Best regards,
Marty Knapp
Knappster Solutions LLC
---




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Marty Knapp]

Hey Devin,
I just downloaded the test stack in your bug report and briefly tried it 
in LC 7.1. It seems like scaleFactor is not having that problem in this 
version. I've been using 6.6.5 and haven't noticed anything there either.


Marty

On Oct 13, 2015, at 1:57 PM, Marty Knapp  wrote:

I'm playing around with scaleFactor on a desktop app as sort of a "zoom view" 
feature. But there are some weirdnesses about it, especially in terms of screen 
placement. For example, when the scaleFactor is anything but 1, setting the loc of a 
stack is way off. Like setting the loc of a stack to the screenLoc does not place it at 
the center of the screen.

It would be nice to be able to scale a window in/out from the topLeft or from 
the center of the stack too.

I tried a few things, but nothing I came up with was very acceptable. Anybody 
else played with this?

Marty,

Is what you’re seeing anything like I wrote in this bug report: 
http://quality.runrev.com/show_bug.cgi?id=13883

I included a screen capture of what was happening. If your issue seems like the 
same thing, leave a comment on the bug report. It would be nice if the mother 
ship could tighten this feature up a bit.

Regards,

Devin

Devin Asay
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Marty Knapp]

Thanks Scott - I'll take a look.

Marty

Believe me, Marty, that was the first thing I asked about.  I sent them a
demo stack that illustrated the limitations of the effect, but they said
they couldn't make the behavior work the way I (and you) want.

You can try the demo stack via your message box:
go url "http://tactilemedia.com/download/WindowScalingExample.livecode;


Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/13/15, 3:01 PM, "use-livecode on behalf of Marty Knapp"
 wrote:


Hey Scott,
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.

Marty

Many of us tried to do the same thing when the feature was first
announced.  Unfortunately, you can't really use it for a zoom effect, at
least not since I last looked into this.  As you've seen, the stack
jumps
around as the scale is changed, and even if you reposition it
dynamically,
the results aren't the best.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/13/15, 12:57 PM, "use-livecode on behalf of Marty Knapp"
 wrote:


I'm playing around with scaleFactor on a desktop app as sort of a "zoom
view" feature. But there are some weirdnesses about it, especially in
terms of screen placement. For example, when the scaleFactor is
anything
but 1, setting the loc of a stack is way off. Like setting the loc of a
stack to the screenLoc does not place it at the center of the screen.

It would be nice to be able to scale a window in/out from the topLeft
or

>from the center of the stack too.

I tried a few things, but nothing I came up with was very acceptable.
Anybody else played with this?

Marty K





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Scott Rossi]

There's a more substantial limitation, Terry: it's not possible to display
objects that remain unaffected by the scaleFactor within a stack that is
changed by the scaleFactor.

What I had envisioned was something along the line of Google maps, where
you have a floating slider overlaid on the map that scales the map up and
down.  Because the scaleFactor affects all contents within the stack
window, any control you include to adjust scaling will itself get scaled,
making this type of control arrangement unusable.  That's why the slider
in the demo is contained in a separate window.  On desktop, you could fake
a "built-in" slider control on top of the map using a custom windowShape,
but obviously that won't work on mobile.

Anyway, if LiveCode isn't able to keep the stack perfectly sized while its
contents are scaled up and down, this direction isn't a good one for
scaling effects.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/13/15, 3:41 PM, "use-livecode on behalf of Terry Judd"
 wrote:

>Good demo Scott. It doesn¹t look so bad if you set the stack¹s fullscreen
>property to true but that¹s probably not that useful on desktops.
>
>Terry...
>
>On 14/10/2015 9:17 am, "use-livecode on behalf of Scott Rossi"
>sc...@tactilemedia.com> wrote:
>
>>Believe me, Marty, that was the first thing I asked about.  I sent them a
>>demo stack that illustrated the limitations of the effect, but they said
>>they couldn't make the behavior work the way I (and you) want.
>>
>>You can try the demo stack via your message box:
>>go url "http://tactilemedia.com/download/WindowScalingExample.livecode;
>>
>>
>>Regards,
>>
>>Scott Rossi
>>Creative Director
>>Tactile Media, UX/UI Design
>>
>>
>>
>>
>>On 10/13/15, 3:01 PM, "use-livecode on behalf of Marty Knapp"
>>>martyknapps...@gmail.com> wrote:
>>
>>>Hey Scott,
>>>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.
>>>
>>>Marty
 Many of us tried to do the same thing when the feature was first
 announced.  Unfortunately, you can't really use it for a zoom effect,
at
 least not since I last looked into this.  As you've seen, the stack
jumps
 around as the scale is changed, and even if you reposition it
dynamically,
 the results aren't the best.

 Regards,

 Scott Rossi
 Creative Director
 Tactile Media, UX/UI Design




 On 10/13/15, 12:57 PM, "use-livecode on behalf of Marty Knapp"
  wrote:

> I'm playing around with scaleFactor on a desktop app as sort of a
>"zoom
> view" feature. But there are some weirdnesses about it, especially in
> terms of screen placement. For example, when the scaleFactor is
>anything
> but 1, setting the loc of a stack is way off. Like setting the loc of
>a
> stack to the screenLoc does not place it at the center of the screen.
>
> It would be nice to be able to scale a window in/out from the topLeft
>or
 >from the center of the stack too.
> I tried a few things, but nothing I came up with was very acceptable.
> Anybody else played with this?
>
> Marty K
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>>
>>>-- 
>>>Best regards,
>>>Marty Knapp
>>>Knappster Solutions LLC
>>>---
>>>
>>>
>>>
>>>
>>>___
>>>use-livecode mailing list
>>>use-livecode@lists.runrev.com
>>>Please visit this url to subscribe, unsubscribe and manage your
>>>subscription preferences:
>>>http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>>
>>___
>>use-livecode mailing list
>>use-livecode@lists.runrev.com
>>Please visit this url to subscribe, unsubscribe and manage your
>>subscription preferences:
>>http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:

Re: scaleFactor strangeness

[Richard Gaskin]

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?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Terry Judd]

Good demo Scott. It doesn¹t look so bad if you set the stack¹s fullscreen
property to true but that¹s probably not that useful on desktops.

Terry...

On 14/10/2015 9:17 am, "use-livecode on behalf of Scott Rossi"
 wrote:

>Believe me, Marty, that was the first thing I asked about.  I sent them a
>demo stack that illustrated the limitations of the effect, but they said
>they couldn't make the behavior work the way I (and you) want.
>
>You can try the demo stack via your message box:
>go url "http://tactilemedia.com/download/WindowScalingExample.livecode;
>
>
>Regards,
>
>Scott Rossi
>Creative Director
>Tactile Media, UX/UI Design
>
>
>
>
>On 10/13/15, 3:01 PM, "use-livecode on behalf of Marty Knapp"
>martyknapps...@gmail.com> wrote:
>
>>Hey Scott,
>>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.
>>
>>Marty
>>> Many of us tried to do the same thing when the feature was first
>>> announced.  Unfortunately, you can't really use it for a zoom effect,
>>>at
>>> least not since I last looked into this.  As you've seen, the stack
>>>jumps
>>> around as the scale is changed, and even if you reposition it
>>>dynamically,
>>> the results aren't the best.
>>>
>>> Regards,
>>>
>>> Scott Rossi
>>> Creative Director
>>> Tactile Media, UX/UI Design
>>>
>>>
>>>
>>>
>>> On 10/13/15, 12:57 PM, "use-livecode on behalf of Marty Knapp"
>>> >> martyknapps...@gmail.com> wrote:
>>>
 I'm playing around with scaleFactor on a desktop app as sort of a
"zoom
 view" feature. But there are some weirdnesses about it, especially in
 terms of screen placement. For example, when the scaleFactor is
anything
 but 1, setting the loc of a stack is way off. Like setting the loc of
a
 stack to the screenLoc does not place it at the center of the screen.

 It would be nice to be able to scale a window in/out from the topLeft
or
>>> >from the center of the stack too.
 I tried a few things, but nothing I came up with was very acceptable.
 Anybody else played with this?

 Marty K

 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>>
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>>subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>>-- 
>>Best regards,
>>Marty Knapp
>>Knappster Solutions LLC
>>---
>>
>>
>>
>>
>>___
>>use-livecode mailing list
>>use-livecode@lists.runrev.com
>>Please visit this url to subscribe, unsubscribe and manage your
>>subscription preferences:
>>http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: scaleFactor strangeness

[Terry Judd]

Yep, gotcha. On mobile you’d have to inversely rescale and dynamically
reposition the slider control at the same time. Hard to see that working
smoothly.

Terry...

On 14/10/2015 9:54 am, "use-livecode on behalf of Scott Rossi"
 wrote:

>There's a more substantial limitation, Terry: it's not possible to display
>objects that remain unaffected by the scaleFactor within a stack that is
>changed by the scaleFactor.
>
>What I had envisioned was something along the line of Google maps, where
>you have a floating slider overlaid on the map that scales the map up and
>down.  Because the scaleFactor affects all contents within the stack
>window, any control you include to adjust scaling will itself get scaled,
>making this type of control arrangement unusable.  That's why the slider
>in the demo is contained in a separate window.  On desktop, you could fake
>a "built-in" slider control on top of the map using a custom windowShape,
>but obviously that won't work on mobile.
>
>Anyway, if LiveCode isn't able to keep the stack perfectly sized while its
>contents are scaled up and down, this direction isn't a good one for
>scaling effects.
>
>Regards,
>
>Scott Rossi
>Creative Director
>Tactile Media, UX/UI Design
>
>
>
>
>On 10/13/15, 3:41 PM, "use-livecode on behalf of Terry Judd"
>terry.j...@unimelb.edu.au> wrote:
>
>>Good demo Scott. It doesn¹t look so bad if you set the stack¹s fullscreen
>>property to true but that¹s probably not that useful on desktops.
>>
>>Terry...
>>
>>On 14/10/2015 9:17 am, "use-livecode on behalf of Scott Rossi"
>>>sc...@tactilemedia.com> wrote:
>>
>>>Believe me, Marty, that was the first thing I asked about.  I sent them
>>>a
>>>demo stack that illustrated the limitations of the effect, but they said
>>>they couldn't make the behavior work the way I (and you) want.
>>>
>>>You can try the demo stack via your message box:
>>>go url "http://tactilemedia.com/download/WindowScalingExample.livecode;
>>>
>>>
>>>Regards,
>>>
>>>Scott Rossi
>>>Creative Director
>>>Tactile Media, UX/UI Design
>>>
>>>
>>>
>>>
>>>On 10/13/15, 3:01 PM, "use-livecode on behalf of Marty Knapp"
>>>>>martyknapps...@gmail.com> wrote:
>>>
Hey Scott,
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.

Marty
> Many of us tried to do the same thing when the feature was first
> announced.  Unfortunately, you can't really use it for a zoom effect,
>at
> least not since I last looked into this.  As you've seen, the stack
>jumps
> around as the scale is changed, and even if you reposition it
>dynamically,
> the results aren't the best.
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 10/13/15, 12:57 PM, "use-livecode on behalf of Marty Knapp"
>  martyknapps...@gmail.com> wrote:
>
>> I'm playing around with scaleFactor on a desktop app as sort of a
>>"zoom
>> view" feature. But there are some weirdnesses about it, especially
>>in
>> terms of screen placement. For example, when the scaleFactor is
>>anything
>> but 1, setting the loc of a stack is way off. Like setting the loc
>>of
>>a
>> stack to the screenLoc does not place it at the center of the
>>screen.
>>
>> It would be nice to be able to scale a window in/out from the
>>topLeft
>>or
> >from the center of the stack too.
>> I tried a few things, but nothing I came up with was very
>>acceptable.
>> Anybody else played with this?
>>
>> Marty K
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


-- 
Best regards,
Marty Knapp
Knappster Solutions LLC
---




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>>
>>>

Re: scaleFactor strangeness

[Scott Rossi]

Believe me, Marty, that was the first thing I asked about.  I sent them a
demo stack that illustrated the limitations of the effect, but they said
they couldn't make the behavior work the way I (and you) want.

You can try the demo stack via your message box:
go url "http://tactilemedia.com/download/WindowScalingExample.livecode;


Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/13/15, 3:01 PM, "use-livecode on behalf of Marty Knapp"
 wrote:

>Hey Scott,
>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.
>
>Marty
>> Many of us tried to do the same thing when the feature was first
>> announced.  Unfortunately, you can't really use it for a zoom effect, at
>> least not since I last looked into this.  As you've seen, the stack
>>jumps
>> around as the scale is changed, and even if you reposition it
>>dynamically,
>> the results aren't the best.
>>
>> Regards,
>>
>> Scott Rossi
>> Creative Director
>> Tactile Media, UX/UI Design
>>
>>
>>
>>
>> On 10/13/15, 12:57 PM, "use-livecode on behalf of Marty Knapp"
>> > martyknapps...@gmail.com> wrote:
>>
>>> I'm playing around with scaleFactor on a desktop app as sort of a "zoom
>>> view" feature. But there are some weirdnesses about it, especially in
>>> terms of screen placement. For example, when the scaleFactor is
>>>anything
>>> but 1, setting the loc of a stack is way off. Like setting the loc of a
>>> stack to the screenLoc does not place it at the center of the screen.
>>>
>>> It would be nice to be able to scale a window in/out from the topLeft
>>>or
>> >from the center of the stack too.
>>> I tried a few things, but nothing I came up with was very acceptable.
>>> Anybody else played with this?
>>>
>>> Marty K
>>>
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>>subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>-- 
>Best regards,
>Marty Knapp
>Knappster Solutions LLC
>---
>
>
>
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode