quirk in group resize behavior
ambassador at fourthworld.com
Tue Jun 21 16:09:11 CEST 2016
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.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode