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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps