Re: scaleFactor strangeness

[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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

@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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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.

Re: scaleFactor strangeness

> 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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

> 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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

> 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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

> 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

Re: scaleFactor strangeness

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,

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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

Re: scaleFactor strangeness

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:

Re: scaleFactor strangeness

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"

Re: scaleFactor strangeness

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