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