quirk in group resize behavior

[Richard Gaskin]

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 contents in the expected way. Could even use the arithmetic
 >> from the full screen mode code.
 >
 > Hmm… While transformed groups would be cool (I’m sure Richard will
 > chime in on that) they introduce some difficult to deal with issues
 > around object rects. For example if you get the rect of an object
 > in a scaled group do you get the transformed rect or the
 > untransformed rect?

As a long-time advocate of providing a means of scaling a group's 
contents (see <http://quality.livecode.com/show_bug.cgi?id=11842>), I 
would love to see a scaleFactor implemented for them, and it needn't be 
any more complicated than what we currently do with stacks:  the 
scaleFactor is a view property, affecting display only; coordinates 
continue to use native resolution.

That said, I would prefer that any addition to groups not be overloaded 
with fullScreen options.  Scalefactor and fullscreen are very different 
things, and while I suppose there are cases where fullscreen may be 
useful for groups that would be a separate project from adding a 
scaleFactor property for groups, just as they are separate properties 
for stacks today.

But neither addresses the core concern:
 > Having said all that I think this is a bit of a tangent from the
 > issue we need to work out which is the behavior of resizing a group
 > when the bottomLeft is maintained.

Given our long history of working with scrolling windows, my first 
inclination is to suggest that groups be automatically anchored to the 
topLeft, similar to how windows work.

But groups aren't windows, and could benefit from being able to handle a 
wider range of options.

I very much like Terry's suggestions of being able to set a property, 
perhaps something like "the anchorCorner" (or if you want to get geeky, 
"the renderOriginPoint", but let's not get that geeky <g>).  Set to 
empty by default, it would continue with the behavior we have now.  But 
when set to any corner, that corner would become the point at which 
content coordinate origin is preserved when the group is resized.

By allowing corners other than topLeft this property can conceivably be 
even more useful, far beyond the current use case.

In my view, Terry has the best solution I can think of offhand.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com