Live WWDC keynote feed
ambassador at fourthworld.com
Wed Jun 13 09:28:59 EDT 2012
Monte Goulding wrote:
>> Pixelation is a byproduct of raster images, and the Android dev
>> guides already provide a good system for supplying an app with
>> four sets of raster images to handle the four main categories
>> of display types - extra bonus points if the engine could handle
>> dynamic swapping of image sets accordingly.
> I would suggest reasonable first step would be to add a cross
> platform screenScale function. From there much of the other stuff
> could be scripted.
If I understand you correctly this would be equivalent to what the
Android API refers to as "pixel density".
For the benefit of those who've used other tools it may be useful to
simply call it by its API name, giving us a "pixelDensity" function,
which I believe is a one-liner in the Android API and essential to good
support of the Android ecosystem's device diversity.
>> Once coordinates are abstracted, it would be ideal to be able to
>> apply them to specific objects in addition to the card or stack
>> as a whole.
> This is a really interesting idea and I must have missed the
> discussion on it. I love playing with ideas like this even though
> they rarely get implemented.
> Let's say it was implemented and an object with a scale of 1 had to
> operate on an object inside a group with a scale of 2 (yes poor
> design I know) what scale would the operating object need to use?
> Would it need to multiply by the scale of the group before setting
> the location of the control inside it?
> What about groups within groups with different scales? Is the scale
> relative to the parent or the screen density?
Hard to say. Can you describe a specific workflow example in which that
would be useful?
I would suggest perhaps implementing this in stages like behaviors:
What we really want with behaviors is to be able to nest them, opening
the door to more OOP-like messaging with subclasses, etc. But what we
needed most was at least one level of behaviors, and that's what we have
Similarly, if a first pass at scaled rendering were limited to stacks
and groups, it would support at least 95% of the use cases I can think
of offhand, plenty to keep me busy until a more granular version were
implemented after we work out the details for such granularity as you
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys
More information about the use-livecode