Live WWDC keynote feed
monte at sweattechnologies.com
Wed Jun 13 17:31:25 CDT 2012
> > 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.
It doesn't really matter what it's called but the language already has the concept of a scale ratio so it would make more sense to use the term scale to me rather than parrot the syntax of a single platform. Filter for scale in the dictionary.
> >> 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?
Hmm... A group within a group with different scales? Maybe a map with a mini overview map in the corner.
> 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.
I've always wanted a view object (or property of a group) where a stack or group could be presented within the view. Now if the view object had a scale ratio then we are in business are we not ;-)
M E R Goulding
Software development services
Bespoke application development for vertical markets
mergExt - There's an external for that!
More information about the use-livecode