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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
