> > 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.
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 ;-) Cheers -- M E R Goulding Software development services Bespoke application development for vertical markets mergExt - There's an external for that! _______________________________________________ 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
