Live WWDC keynote feed

Richard Gaskin 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.
 >> <http://developer.android.com/guide/practices/screens_support.html>
 >
 > 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.

Amen.

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 
now.

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 
noted above.

--
  Richard Gaskin
  Fourth World
  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 mailing list