Live WWDC keynote feed

[Richard Gaskin]

Monte Goulding wrote:

 > Hi Richard
 >
 >> One step closer to a "scale card" command....
 >
 > Are you referring to http://quality.runrev.com/show_bug.cgi?id=6589
 >
 > A scaleToFit stack property would be simpler than a command wouldn't
 > it?

Easier still to not provide anything at all. :)

 > As long as things didn't just end up pixelated. Options might
 > be letterbox,stretch and none. Anything other than none would
 > mean resizeStack messages wouldn't need to be sent any more.

Whether that will suffice depends on what you want to do.

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>

But that's just for whole-screen solutions.  I'm thinking of something more.

Alejandro Tejada has a similar take on this to where I'm coming from:

 > Could that be similar to a proposed
 > (at least in this mail list) property
 > for groups?

One and the same.

 > For example, if you have a group with many
 > controls, using this proposed "scale" property
 > you could write:
 >
 > set the scale of grp 1 to 250 without scrollbars
 > (250 % percent of original size or 2.5x larger)
 > The option of "with/without scrollbars" would
 > allows greater flexibility. Implemented in this
 > way, that property would be really useful.

Exactly.

Here's what I'm thinking:

Resolution independence is no longer an option, but truly a requirement. 
  To pull that off RunRev would need to abstract the screen metrics so 
that the units we work with aren't specifically pixels per se, but a 
unit that gets interpreted dynamically depending on the target resolution.

We could stop there, with just one pixel density for everything at 
runtime and that would help with the question of handling so-called 
"retina" displays and other pixel densities.

But such an implementation would miss an opportunity for something more:

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.

If we had that, then we can make all sorts of really useful zoom view 
features in our apps.

Even if limited to groups, as Alejandro suggests, the scope of new 
features we could add would be profound, enabling many apps to support 
the sorts of features users are accustomed to.

Drawing programs, print layout, and more - all become zoomable with 
relative ease once the engine provides us with abstract coordinates.

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