Re: Scalefactor positioning

[J. Landman Gay via use-livecode]

Thanks Bernd. Since all scaled coordinates are translated to card 
coordinates I guess I assumed the stack window position would be translated 
too. In retrospect it makes sense.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On March 8, 2023 5:59:21 PM "Niggemann, Bernd via use-livecode" 
 wrote:



J. Landman Gay wrote
I need to set the scalefactor of a stack and position it at the screenloc.



on mouseUp
  local tScaleFactor, tScreenLoc, tNewStackLoc
  put the scaleFactor of this stack into tScaleFactor
  put the screenLoc into tScreenLoc
  put item 1 of tScreenLoc / tScaleFactor into item 1 of tNewStackLoc
  put item 2 of tScreenLoc / tScaleFactor into item 2 of tNewStackLoc
  set the loc of this stack to tNewStackLoc
end mouseUp

This works for me

Kind regards
Bernd

___
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 positioning

[Niggemann, Bernd via use-livecode]

> J. Landman Gay wrote
> I need to set the scalefactor of a stack and position it at the screenloc.


on mouseUp
   local tScaleFactor, tScreenLoc, tNewStackLoc
   put the scaleFactor of this stack into tScaleFactor
   put the screenLoc into tScreenLoc
   put item 1 of tScreenLoc / tScaleFactor into item 1 of tNewStackLoc
   put item 2 of tScreenLoc / tScaleFactor into item 2 of tNewStackLoc
   set the loc of this stack to tNewStackLoc
end mouseUp

This works for me

Kind regards
Bernd

___
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

Scalefactor positioning

[J. Landman Gay via use-livecode]

I need to set the scalefactor of a stack and position it at the screenloc.

  set the scalefactor of this stack to 2
  set the loc of this stack to the screenloc

It doesn't work. The stack loc is always reported as the position of the stack at scalefactor 
1.0 regardless of where it actually is on screen. When setting it to 2 it jumps to a position I 
can't identify. Using "this window" instead of "this stack" doesn't help.


I think I need to calculate a position to get around this but I'm not sure how. And maybe this 
is a bug?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

[Knapp Martin via use-livecode]

Thank you! Works great.

> On Aug 16, 2018, at 3:50 AM, Håkan Liljegren via use-livecode 
>  wrote:
> 
> As the screenrect is the same but virtually larger / smaller based on the 
> scaleFactor you need calculate the scale factor based on the current 
> scaleFactor and the new scaleFactor
> 
> Try this:
> on changeScaleFactor pNewScale
>put the scaleFactor of this stack into tScale
>put tScale / pNewScale into tFactor
>put the topLeft of this stack into tTL
>multiply item 1 of tTL by tFactor
>multiply item 2 of tTl by tFactor
>set the scaleFactor of this stack to pNewScale
>set the topLeft of this stack to tTL
> end changeScaleFactor
> 
> Of course you can substitute topLeft with something else if you want another 
> corner or the center to be the fix point.
> 
> :-Håkan
> On 16 Aug 2018, 01:11 +0200, Peter Bogdanoff via use-livecode 
> , wrote:
>> I too am using scaleFactor and ran into this issue of the difficulty of 
>> windows moving around and even off screen. It seems that when scaleFactor is 
>> invoked the entire screen is now virtual and calculations have to be made to 
>> position the window where you want it to be visually. Unfortunately, those 
>> exact calculations were beyond me at the time I implemented scaleFactor, so 
>> my windows do still move somewhat. But if someone else has a method/formula 
>> for window placement I too would be interested.
>> 
>> Peter Bogdanoff
>> ArtsInteractive
>> 
>> 
>>> On Aug 15, 2018, at 3:02 PM, Knapp Martin via use-livecode 
>>>  wrote:
>>> 
>>> I know that scaleFactor is not intended to be a "zoom view" feature for 
>>> desktop, but in lieu of actually having zoom views, I really need to use it 
>>> to allow the user to enlarge or reduce the window size for a Mac and 
>>> Windows app I’m working on. What I would like is for it to shrink or grow 
>>> from the topLeft point on the screen but I can't seem to figure out a way 
>>> to keep it from jumping around. I would like to have scaleFactors from .5 
>>> to 1.5. Anybody tackled this one?
>>> 
>>> Thanks,
>>> Marty


___
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

[Håkan Liljegren via use-livecode]

As the screenrect is the same but virtually larger / smaller based on the 
scaleFactor you need calculate the scale factor based on the current 
scaleFactor and the new scaleFactor

Try this:
on changeScaleFactor pNewScale
   put the scaleFactor of this stack into tScale
   put tScale / pNewScale into tFactor
   put the topLeft of this stack into tTL
   multiply item 1 of tTL by tFactor
   multiply item 2 of tTl by tFactor
   set the scaleFactor of this stack to pNewScale
   set the topLeft of this stack to tTL
end changeScaleFactor

Of course you can substitute topLeft with something else if you want another 
corner or the center to be the fix point.

:-Håkan
On 16 Aug 2018, 01:11 +0200, Peter Bogdanoff via use-livecode 
, wrote:
> I too am using scaleFactor and ran into this issue of the difficulty of 
> windows moving around and even off screen. It seems that when scaleFactor is 
> invoked the entire screen is now virtual and calculations have to be made to 
> position the window where you want it to be visually. Unfortunately, those 
> exact calculations were beyond me at the time I implemented scaleFactor, so 
> my windows do still move somewhat. But if someone else has a method/formula 
> for window placement I too would be interested.
>
> Peter Bogdanoff
> ArtsInteractive
>
>
> > On Aug 15, 2018, at 3:02 PM, Knapp Martin via use-livecode 
> >  wrote:
> >
> > I know that scaleFactor is not intended to be a "zoom view" feature for 
> > desktop, but in lieu of actually having zoom views, I really need to use it 
> > to allow the user to enlarge or reduce the window size for a Mac and 
> > Windows app I’m working on. What I would like is for it to shrink or grow 
> > from the topLeft point on the screen but I can't seem to figure out a way 
> > to keep it from jumping around. I would like to have scaleFactors from .5 
> > to 1.5. Anybody tackled this one?
> >
> > Thanks,
> > Marty
> > ___
> > 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

[Peter Bogdanoff via use-livecode]

I too am using scaleFactor and ran into this issue of the difficulty of windows 
moving around and even off screen. It seems that when scaleFactor is invoked 
the entire screen is now virtual and calculations have to be made to position 
the window where you want it to be visually. Unfortunately, those exact 
calculations were beyond me at the time I implemented scaleFactor, so my 
windows do still move somewhat. But if someone else has a method/formula for 
window placement I too would be interested.

Peter Bogdanoff
ArtsInteractive


> On Aug 15, 2018, at 3:02 PM, Knapp Martin via use-livecode 
>  wrote:
> 
> I know that scaleFactor is not intended to be a "zoom view" feature for 
> desktop, but in lieu of actually having zoom views, I really need to use it 
> to allow the user to enlarge or reduce the window size for a Mac and Windows 
> app I’m working on. What I would like is for it to shrink or grow from the 
> topLeft point on the screen but I can't seem to figure out a way to keep it 
> from jumping around. I would like to have scaleFactors from .5 to 1.5. 
> Anybody tackled this one?
> 
> Thanks,
> Marty
> ___
> 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

scaleFactor

[Knapp Martin via use-livecode]

I know that scaleFactor is not intended to be a "zoom view" feature for 
desktop, but in lieu of actually having zoom views, I really need to use it to 
allow the user to enlarge or reduce the window size for a Mac and Windows app 
I’m working on. What I would like is for it to shrink or grow from the topLeft 
point on the screen but I can't seem to figure out a way to keep it from 
jumping around. I would like to have scaleFactors from .5 to 1.5. Anybody 
tackled this one?

Thanks,
Marty
___
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: screenloc not actually centered after changing scalefactor (was Screen Resolution for Desktop Apps)

[Nicolas Cueto via use-livecode]

Jacqueline yet again saves the day. Thank you!

--
N.

On 2 January 2018 at 08:34, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 12/31/17 7:31 PM, Nicolas Cueto via use-livecode wrote:
>
>> To do "some calculations", I thought of comparing the loc to the
>> scalefactor. So ran the standalone on three devices, but saw no consistent
>> corelation between the differing locs and the scalefactor.
>>
>> So, still no clue what to use for these calculations...
>>
>
> My math skills are terrible so we need someone more clever to fix my
> calculation. But this seems to work for most scalefactors until you get
> down to about 0.6 or lower:
>
> on setloc pScale
>   -- pScale = the desired scaleFactor
>   put the screenloc into tSLoc
>   if pScale <= 1 then
> put 1 + (1-pScale) into tRatio
>   else
> put 1/pScale into tRatio
>   end if
>   put item 1 of tSLoc * tRatio into item 1 of tNewLoc
>   put item 2 of tSLoc * tRatio into item 2 of tNewLoc
>   set the scalefactor of this stack to pScale
>   set the loc of this stack to tNewLoc
> end setloc
>
> I'm pretty sure there's a way to calculate the ratio without the "if"
> clause so that it works for both large and small scales and I'm not sure
> why it breaks at about 0.6. Hopefully one of our math gurus can advise.
>
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.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: screenloc not actually centered after changing scalefactor (was Screen Resolution for Desktop Apps)

[J. Landman Gay via use-livecode]

On 12/31/17 7:31 PM, Nicolas Cueto via use-livecode wrote:

To do "some calculations", I thought of comparing the loc to the
scalefactor. So ran the standalone on three devices, but saw no consistent
corelation between the differing locs and the scalefactor.

So, still no clue what to use for these calculations...


My math skills are terrible so we need someone more clever to fix my 
calculation. But this seems to work for most scalefactors until you get 
down to about 0.6 or lower:


on setloc pScale
  -- pScale = the desired scaleFactor
  put the screenloc into tSLoc
  if pScale <= 1 then
put 1 + (1-pScale) into tRatio
  else
put 1/pScale into tRatio
  end if
  put item 1 of tSLoc * tRatio into item 1 of tNewLoc
  put item 2 of tSLoc * tRatio into item 2 of tNewLoc
  set the scalefactor of this stack to pScale
  set the loc of this stack to tNewLoc
end setloc

I'm pretty sure there's a way to calculate the ratio without the "if" 
clause so that it works for both large and small scales and I'm not sure 
why it breaks at about 0.6. Hopefully one of our math gurus can advise.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: screenloc not actually centered after changing scalefactor (was Screen Resolution for Desktop Apps)

[Dr. Hawkins via use-livecode]

On Sun, Dec 31, 2017 at 5:31 PM, Nicolas Cueto via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> To do "some calculations", I thought of comparing the loc to the
> scalefactor. So ran the standalone on three devices, but saw no consistent
> corelation between the differing locs and the scalefactor.
>
> I took a stab at it a few years ago, and failed.

I found no coherent relationship between the location on my iMac screen and
what livecode reported once I changed  the scaleFactor of the stack.  With
each 10% increase, the stack seems to move (usually) right, and also up or
down, possibly causing the menubar to be above the screen.

I also see an intermittent issue that livecode things the mouse pointer is
about an inch higher on the screen than it is, but the horizontal seems
correct.  This also seems be be limited to browse rather than select mode.


-- 
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: screenloc not actually centered after changing scalefactor (was Screen Resolution for Desktop Apps)

[Nicolas Cueto via use-livecode]

> You may have to do some calculations based on the scalefactor, in order
to adjust the visual location.

Thanks Jacqueline, but still confused.

To do "some calculations", I thought of comparing the loc to the
scalefactor. So ran the standalone on three devices, but saw no consistent
corelation between the differing locs and the scalefactor.

So, still no clue what to use for these calculations...

On a perhaps related topic. Every time I start LC on that devpt PC
(Windows), the LC menu bar opens mostly hidden offscreen. So I have to drag
it left to be fully onscreen.

So, I guess if LC itself can't get it right, what hope is there for moi.

 ¡Feliz año nuevo!

​--
Nicolas Cueto​
___
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: screenloc not actually centered after changing scalefactor (was Screen Resolution for Desktop Apps)

[J. Landman Gay via use-livecode]

On 12/27/17 9:19 PM, Nicolas Cueto via use-livecode wrote:

Problem is, after opening the standalone on different PCs the rescaling
fits the monitor, but the window is not centered despite the "set the loc
to screenloc" command.


It looks like the stack loc is being calculated at scalefactor 1, 
regardless of the actual scalefactor of the stack. You may have to do 
some calculations based on the scalefactor, in order to adjust the 
visual location.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

screenloc not actually centered after changing scalefactor (was Screen Resolution for Desktop Apps)

[Nicolas Cueto via use-livecode]

Following upon Jacqueline's advice on the original thread, here is my stack
script for modifying scalefactor based on monitor screenrect differences
(i.e., between the monitor I developed the stack and other monitors):

///
on preopenstack
   defaultStackAppearance
end preopenstack

on defaultStackAppearance
   lock screen
   set the fullscreen of this stack to false
   set the width of this stack to 1126
   set the height of this stack to 627

   -- Set to the lower of two screenrect-based ratios.
   -- On the monitor I developed this app,
   -- 1152 was item 3 (width) of the working screenrect and
   -- 682 was item 4 (height) of the working screenrect.

   put round((item 3 of the working screenrect) / 1152,2) into ratio_width
   put round((item 4 of the working screenrect) / 682,2) into ratio_height
   if ratio_width > ratio_height then
  -- current monitor is wider then devpt monitor, so set to height ratio
  set the scalefactor of this stack to ratio_height
   else
  -- current monitor is taller than devpt monitor, so set to width ratio
  set the scalefactor of this stack to ratio_width
   end if
   set the loc of this stack to the screenloc
   unlock screen
end defaultStackAppearance
///

Problem is, after opening the standalone on different PCs the rescaling
fits the monitor, but the window is not centered despite the "set the loc
to screenloc" command.

Suggestions?

Thank you.

--
Nicolas Cueto
___
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

contectRect and scaleFactor

[Dan Friedman via use-livecode]

So, I have a stack that I set the scaleFactor to 1.5 if it’s on a iPhone (I 
leave it at 1 if it’s an iPad).  All is fine, looks great!   However, when I 
add a native scroller to a locked group, the contectRect doesn’t take the 
scaleFactor into account.  So, the scroller scrolls too far to the right and 
the bottom.  I would have thought this would have fixed it, but it’s not right:

if the scaleFactor of this stack <> 1 then
put the scaleFactor of this stack into tFactor
put mobileControlGet(scrollerName,"contentRect") into fRect

put round(item 3 of fRect/ tFactor) into item 3 of fRect
subtract round(item 1 of fRect/ tFactor) from item 3 of fRect

put round(item 4 of fRect/ tFactor) into item 4 of fRect
subtract round(item 2 of fRect/ tFactor) from item 4 of fRect

mobileControlSet scrollerName,"contentRect",fRect
end if

Anyone have any ideas how to correct the scroller so it correctly stays in the 
bounds like it does when  the scaleFactor = 1?

Thanks in advance!
-Dan
___
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: Import or export snapshot at current scaleFactor

[Terry Judd via use-livecode]

Thanks Jim, that’s perfect! I don’t know how many times I’ve looked at the 
import/export command in the dictionary and not seen the size modifier.

Much appreciated.

Terry...

On 6/04/2017 9:14 am, "use-livecode on behalf of Jim Lambert via use-livecode" 
 wrote:

Terry,

Try this

import snapshot from ObjRef at size (the width of ObjRef * 
scaleBy),(the height of ObjRef * scaleBy)

Where ObjRef is the object whose snapshot you want to import and scaleBy is 
the scaling factor. So something like:

import snapshot from grp 1 at size (the width of grp 1 * 2),(the height 
of grp 1 * 2)

If that produces an the image you need just change the command to an export 
snapshot command.

Jim Lambert

___
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: Import or export snapshot at current scaleFactor

[Jim Lambert via use-livecode]

Terry,

Try this

import snapshot from ObjRef at size (the width of ObjRef * 
scaleBy),(the height of ObjRef * scaleBy)

Where ObjRef is the object whose snapshot you want to import and scaleBy is the 
scaling factor. So something like:

import snapshot from grp 1 at size (the width of grp 1 * 2),(the height 
of grp 1 * 2)

If that produces an the image you need just change the command to an export 
snapshot command.

Jim Lambert

___
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

Import or export snapshot at current scaleFactor

[Terry Judd via use-livecode]

I’m automating the creation of a series of images (mostly graphs or similar) to 
include in some non LC generated reports and I need to be able to produce them 
at a higher than screen resolution so that they will look ok. I was thinking 
that I could just increase the scaleFactor of the stack and use ‘export 
snapshot from ’ to create the images but they are produced at ‘normal’ 
resolution. The workaround (I don’t want to have to recreate everything at a 
larger scale because I’m also using the same LC controls to print to pdfs 
directly) is to use the ‘export snapshot from rect’ but that requires that 
everything is visible on-screen and isn’t obscured by other stuff.

I don’t suppose there is any way to use the ‘export snapshot from ’ 
form and get it to capture the image scaled according to the scaleFactor? And 
if not, is there any chance of this being supported in the future (i.e. is it 
worth a feature request)?

Terry...
___
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: within and scaleFactor

[Roger Eller via use-livecode]

Also the content of option menus remain at 1X scale even though everything
else has increased in size.  #thatsabug

~Roger

On Apr 1, 2017 3:17 PM, "Dan Friedman via use-livecode" <
use-livecode@lists.runrev.com> wrote:

> I call this a bug, would you?
>
> If the scaleFactor of stack “myStack” is set to 2, then within(stack
> “myStack”,the screenMouseLoc) only returns true if the mouse is within the
> rect of stack “myStack” when it’s scaleFactor is set to 1.  Hope I
> explained that logically.
>
> Mac 10.12.2, LC 9.0.0 dp 6.   Worked correctly in LC 7.
>
> -Dan
>
> ___
> 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

within and scaleFactor

[Dan Friedman via use-livecode]

I call this a bug, would you?

If the scaleFactor of stack “myStack” is set to 2, then within(stack 
“myStack”,the screenMouseLoc) only returns true if the mouse is within the rect 
of stack “myStack” when it’s scaleFactor is set to 1.  Hope I explained that 
logically.

Mac 10.12.2, LC 9.0.0 dp 6.   Worked correctly in LC 7.

-Dan

___
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: Help needed with scaleFactor and scaling

[Colin Holgate via use-livecode]

This seems to work (to make button 1 appear to be 100 pixels from the top and 
left, and to appear to be 200 wide and 150 tall):

on fixit
   put random(10)/10 + 1 into it
   set the scalefactor of this stack to it
   set the rect of btn 1 to 100/it,100/it,100/it+100/it,100/it+50/it
end fixit



___
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

Help needed with scaleFactor and scaling

[Dan Friedman via use-livecode]

Can anyone figure out the math to resize a control so it appears to be 
unchanged when you set the scaleFactor of a stack?  For example… you have a 
button who’s rect is 100,100,400,400.  On the screen, it looks to be 300px 
wide.  Now, if you set the scaleFactor to 1.5, what rect do you have to set the 
button to get it to “appear” to remain 300px wide?  At first, I thought it 
would simply be each item of the rect/scaleFactor.  But, that doesn’t do it.  I 
feels like you have to get the DPI of the active display and somehow use that 
as part of the equation.  Any ideas?

Thanks in advance,
-Dan
___
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]]

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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
>>>

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"
>>>> >>> 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,
>&g

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

[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

[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

[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

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

[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

[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

scaleFactor strangeness

[Marty Knapp]

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: rect w/ scaleFactor?

[Ralph DiMola]

This is what I do There is a lot going on here. This function will allow
for the keyboard area. I set the pixelscale to 1 for all devices at startup.
I don't know if other scale factors will affect this function but all one
would need is some constructive multiplies.

function getCardRect
   
--If ignorekeyboard is true then the rect is the entire card is returned
--If ignorekeyboard is false then
-- If ShrinkKeyboard is true then the rect of the available real-estate is
returned
-- If ShrinkKeyboard is false then the top of the rect is off screen but the
canvas size is the same if the keyboard was not there.
--  also in this mode the canvas can be shifted by KeyboardOffet pixels.

   local r1 , r2 , r3 , r4 , tR2 , tR4 , tRectTemp
   
   --return the rect of this card
   if the environment is not "mobile" then
  put item 1 of the rect of this card into R1
  put item 2 of the rect of this card into R2
  put item 3 of the rect of this card into R3
  put item 4 of the rect of this card into R4
   else -- Mobile
  put the screenrect into tRectTemp
  if the ignorekeyboard of this stack then
 put item 1 of the rect of this stack into R1
 put item 2 of the rect of this stack into R2
 put item 3 of the rect of this stack into R3
 put item 4 of the rect of this stack into R4
  else -- Don't Ignore Keyboard
 put 0 into R1
 put item 3 of the effective working screenrect - item 1 of the
effective working screenrect into R3
 if the ShrinkKeyboard of this stack then
put 0 into R2
put item 4 of the effective working screenrect - item 2 of the
effective working screenrect into R4
 else -- Shrink Keyboard
put (item 4 of the effective working screenrect - item 2 of the
effective working screenrect) - item 4 of the rect of this stack into R2
put item 4 of the effective working screenrect - item 2 of the
effective working screenrect into R4
if the KeyboardOffet of this stack is not empty and the
KeyboardOffet of this stack is a number then
   put (item 2 of the rect of this stack - the KeyboardOffet of
this stack) into tR2
   put (item 4 of the rect of this stack - the KeyboardOffet of
this stack) into tR4
   if tR2 >= R2 then
  put tR2 into R2
  put tR4 into R4
   end if -- Offset out of range
end if -- Keyboard Offset
 end if -- Shrink Keyboard
  end if --Ignore Keyboard
   end if -- Mobile
   return (R1,R2,R3,R4)
end getCardRect



Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Richard Gaskin
Sent: Monday, February 09, 2015 3:53 PM
To: How to use LiveCode
Subject: rect w/ scaleFactor?

When the scaleFactor is set to any value other than 1, there appears to be
no relationship between the stack's rect property and its apparent rect on
screen.

"the effective rect..." doesn't help.

How can I obtain the actual on-screen rect of a stack whose scaleFactor is
set to any value other than 1?

--
  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: rect w/ scaleFactor?

[J. Landman Gay]

On 2/9/2015 2:53 PM, Richard Gaskin wrote:

When the scaleFactor is set to any value other than 1, there appears to
be no relationship between the stack's rect property and its apparent
rect on screen.

"the effective rect..." doesn't help.

How can I obtain the actual on-screen rect of a stack whose scaleFactor
is set to any value other than 1?



I don't know if it only applies to card coords or to stacks as well, but 
setting the pixelscale might help.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: rect w/ scaleFactor?

[dunbarx]

Richard.


Uh, oh.


Make a stack with one button and one decent sized field. In the button script:



on mouseUp
   put "" into fld 1
   put the rect of this stack into line 1 of fld 1
   set the scalefactor of this stack to ".5"
   put "0.5=" && the rect of this stack into line 2 of fld 1
   set the scalefactor of this stack to ".75"
   put "0.75=" && the rect of this stack into line 3 of fld 1
   set the scalefactor of this stack to "1.5"
   put "1.5=" && the rect of this stack into line 4 of fld 1
   set the scalefactor of this stack to "1"
end mouseUp


BUT, if you set the scale factor to something other than "1" in the inspector, 
and then:


answer the scaleFactor of this stack, you do get the correct, scaled rects.


Uh, oh


Craig



-Original Message-
From: Richard Gaskin 
To: How to use LiveCode 
Sent: Mon, Feb 9, 2015 3:51 pm
Subject: rect w/ scaleFactor?


When the scaleFactor is set to any value other than 1, there appears to 
be no relationship between the stack's rect property and its apparent 
rect on screen.

"the effective rect..." doesn't help.

How can I obtain the actual on-screen rect of a stack whose scaleFactor 
is set to any value other than 1?

-- 
  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: rect w/ scaleFactor?

[Dave Kilroy]

Hi Richard - I had an issue about setting the loc of a stack with a
scaleFactor that would be calculated as the app opened (to make it close to
fullscreen). What I had to do was to apply the scaleFactor to the loc and
then set the loc of the stack to that - I should think the same would apply
to the stack's rect - apply the scaleFactor it it.

Here is my code from that app:

  --finding out about the screen
  put the screenRect into tScreenRectRaw
  put the working screenRect into tScreenRect
  put item 3 of tScreenRect into tScreenW
  put item 2 of tScreenRect - item 2 of tScreenRectRaw into
tMenuBarHeight
  put item 4 of tScreenRectRaw - item 4 of tScreenRect into
tTaskBarHeight
  put item 4 of tScreenRect - tMenuBarHeight into tScreenH

  --elsewhere I calculate what scaleFactor I need for the app, then I
set the stack to it
  set the scaleFactor of stack "Rewind" to tScaleFactor

  --loc for positioning the stack (before scaleFactor)
  put round(tScreenW/2,0) into tAppLocH 
  put 13 into tTitleBarHeight
  put tMenuBarHeight + tTitleBarHeight + round(tScreenH/2,0) into
tAppLocV 
  
  --loc for positioning the stack (including scaleFactor)
  put round(tAppLocH / tScaleFactor) into tAppLocH
  put round(tAppLocV / tScaleFactor) into tAppLocV
  set the loc of stack "Rewind" to tAppLocH & comma & tAppLocV



-
"Some are born coders, some achieve coding, and some have coding thrust upon 
them." - William Shakespeare & Hugh Senior

--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/rect-w-scaleFactor-tp4688655p4688657.html
Sent from the Revolution - User mailing list archive at Nabble.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

rect w/ scaleFactor?

[Richard Gaskin]

When the scaleFactor is set to any value other than 1, there appears to 
be no relationship between the stack's rect property and its apparent 
rect on screen.


"the effective rect..." doesn't help.

How can I obtain the actual on-screen rect of a stack whose scaleFactor 
is set to any value other than 1?


--
 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 in LiveCode 6.6 (dp1)

[Dave Kilroy]

Yes the potential for scaleFactor is big! But for me the first priority is
being able to control stack positioning, when we get that working smoothly
I'll be a very happy man.

If we can later on 'zoom' in and out of different areas in a stack that
would be some splendid icing on the cake.



-
"Some are born coders, some achieve coding, and some have coding thrust upon 
them." - William Shakespeare & Hugh Senior

--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/scaleFactor-in-LiveCode-6-6-dp1-tp4676455p4676491.html
Sent from the Revolution - User mailing list archive at Nabble.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 in LiveCode 6.6 (dp1)

[Richard Gaskin]

Scott Rossi wrote:


I've been looking for a way to accomplish zooming into (what are
essentially) flow charts, and the scaleFactor property is making this
possible.

...

The biggest restriction in all this is that *everything* in a stack is
scaled.  It would be great if there was a way to keep some elements
not-scaled.


The RunRev team recently pulled out part of a request I made years ago 
into its own request for that:


Can we have the scalingFactor available for the contents of groups?
<http://quality.runrev.com/show_bug.cgi?id=11842>

--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 Follow me on Twitter:  http://twitter.com/FourthWorldSys

___
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 in LiveCode 6.6 (dp1)

[Scott Rossi]

I've been looking for a way to accomplish zooming into (what are
essentially) flow charts, and the scaleFactor property is making this
possible.  The currently behavior is is wonky (need a way to keep the
window dimensions stable while the scaling takes place) but it's working
and shows the potential of doing things like a scalable drawing canvas
like you'd find in any most pro graphics app.  I imagine pinch to zoom
could work in some cases on mobile.

The biggest restriction in all this is that *everything* in a stack is
scaled.  It would be great if there was a way to keep some elements
not-scaled.  Think of the zoom control in Google maps that stays fixed in
size while the map contents are scaled.  You can accomplish this on
desktop by using a separate stack for the controls, but on mobile where
only one stack is visible at a time, I believe you'd have to reverse scale
a zoom control and position it while the other stack contents are scaled.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 2/26/14 8:18 AM, "Dave Kilroy"  wrote:

>Is anyone else making use of scaleFactor?
>
>I'm going to be able to use it in an upcoming piece of work for Windows
>where an app with a complex GUI will be displayed on a range of
>differently
>sized screens - and it will save me from hours of fiddly work - I love it!
>
>It's still not completely 'cooked' as a functionality (locating a stack
>with
>scaleFactor applied could be a bit smoother) but I'm sure it will
>improve...
>
>scaleFactor is definitely my favourite part of 6.6 - but who knows, maybe
>in
>time I'll learn to love 'assert' too
>
>Kind regards
>
>Dave
>
>
>
>-
>"Some are born coders, some achieve coding, and some have coding thrust
>upon them." - William Shakespeare & Hugh Senior
>
>--
>View this message in context:
>http://runtime-revolution.278305.n4.nabble.com/scaleFactor-in-LiveCode-6-6
>-dp1-tp4676455.html
>Sent from the Revolution - User mailing list archive at Nabble.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

scaleFactor in LiveCode 6.6 (dp1)

[Dave Kilroy]

Is anyone else making use of scaleFactor?

I'm going to be able to use it in an upcoming piece of work for Windows
where an app with a complex GUI will be displayed on a range of differently
sized screens - and it will save me from hours of fiddly work - I love it!

It's still not completely 'cooked' as a functionality (locating a stack with
scaleFactor applied could be a bit smoother) but I'm sure it will improve...

scaleFactor is definitely my favourite part of 6.6 - but who knows, maybe in
time I'll learn to love 'assert' too

Kind regards

Dave



-
"Some are born coders, some achieve coding, and some have coding thrust upon 
them." - William Shakespeare & Hugh Senior

--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/scaleFactor-in-LiveCode-6-6-dp1-tp4676455.html
Sent from the Revolution - User mailing list archive at Nabble.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