Re: quirk in group resize behavior

I was thinking gravity relative to the reference corner/center was accurate. Sent from my iPhone > On 22 Jun 2016, at 7:09 AM, Scott Rossi wrote: > > ControlGravity ___ use-livecode mailing list use-livecode@lists.runrev.com

Re: quirk in group resize behavior

ControlGravity was the first property name that came into my mind, but it's not really accurate. In my view, this implies that controls physically move to the designated edge of the group (as an icon does in a button with iconGravity -- why this property wasn't named iconAlignment is beyond me).

Re: quirk in group resize behavior

Hmm... I suspect we don't have resources to do this right now but I'd be interested to discuss how it might work. So I presume what we mean by this is we have 5 options: - topLeft - controls only move with the topLeft - topRight - controls only move with the topRight - bottomLeft - controls

Re: quirk in group resize behavior

Yep... Precisely why I'm asking here although it would seem an odd thing to depend on because you need to be quite precise. One pixel out and it uses the normal code path. You also need to know about it and the docs make no mention... I do suspect it has been around for a long time. > On 22

Re: quirk in group resize behavior

On 6/20/2016 6:17 PM, Monte Goulding wrote: When you resize a group using the selection handles the controls inside stay where they are. This is quite helpful. The code that does that also has an extra condition which means the controls inside the group will also stay where they are if resizing

Re: quirk in group resize behavior

Monte Goulding wrote: >> On 21 Jun 2016, at 10:00 AM, Colin Holgate wrote: >> >> Perhaps it could use the same terminology, and work the same way, >> as full screen modes. The current behavior is effectively noScale, >> and with exactFit, noBorder, showAll, and letterbox, you could move >> the

Re: quirk in group resize behavior

> On 21 Jun 2016, at 10:31 PM, Mike Kerner wrote: > > Isn't this part of what the GM is supposed to do? Yes and no. The GM can’t change the behavior of the engine. If the engine is doing something interesting with the controls of a group in one particular

Re: quirk in group resize behavior

Isn't this part of what the GM is supposed to do? On Mon, Jun 20, 2016 at 9:48 PM, Monte Goulding wrote: > > > On 21 Jun 2016, at 9:55 AM, Terry Judd > wrote: > > > > Yeah, I often get caught out resizing groups and finding that I¹m adding > >

Re: quirk in group resize behavior

> On 21 Jun 2016, at 9:55 AM, Terry Judd wrote: > > Yeah, I often get caught out resizing groups and finding that I¹m adding > unnecessary/unexpected space or cutting off controls when really what I > want to do is anchor the child controls on one or two axes when I

Re: quirk in group resize behavior

> On 21 Jun 2016, at 10:00 AM, Colin Holgate wrote: > > Perhaps it could use the same terminology, and work the same way, as full > screen modes. The current behavior is effectively noScale, and with exactFit, > noBorder, showAll, and letterbox, you could move the

Re: quirk in group resize behavior

. Of course, that does assume you’re able to scale controls. > On Jun 20, 2016, at 7:17 PM, Monte Goulding <mo...@appisle.net> wrote: > > Hi Folks > > One of the recent issues in the IDE caused us to discover/rediscover a quirk > in group resize behavior that I think wou

Re: quirk in group resize behavior

behalf of mo...@appisle.net> wrote: >Hi Folks > >One of the recent issues in the IDE caused us to discover/rediscover a >quirk in group resize behavior that I think would be worthwhile getting >feedback on from the community. I¹m personally struggling to come up with >a use case

quirk in group resize behavior

Hi Folks One of the recent issues in the IDE caused us to discover/rediscover a quirk in group resize behavior that I think would be worthwhile getting feedback on from the community. I’m personally struggling to come up with a use case for it although there very likely is/was one. Perhaps one