Preview of Resolution Independent Control library for RevMobile

[Scott Rossi]

My question would be, are 4 separate images for each control necessary?

You're not going to change density in the middle of session, so only one "scaled" image for each control is needed at a time.  While most of the controls I've been building are groups of graphics (no images), It seems to me that storing multiple versions of the same image consumes file space for no good reason.  Ideally I would imagine you could start out with one hi res image for each control that is scaled down as needed.  Perhaps control images could be scaled dynamically to the needed resolution at startup.

The only reason I can see for having multiples of the same image is if the scaling results are not visually satisfactory, but there might be other considerations.

Scott Rossi
Creative Director
Tactile Media, UX Design

On Jul 26, 2012, at 3:47 AM, Monte Goulding <monte at sweattechnologies.com> wrote:

> The other thing is any images that are used as icons would need to be found if they aren't on that stack. Probably in an icon/image library. What do people think about resizing images as Chipp has done compared to providing 4 sizes. My thought is that the framework could include a plugin that took an image, created and saved the 4 sizes (or used up to 4 supplied image) to icon library stack files for each density. Then the framework would load the correct icon library for the density and all the icons would be right. We could also have folders for each density for images that are only needed occasionally so you don't what them in memory etc.
> 
> To resize a control we need to come up with a command that can accept a control id and a density. If we want to be able to work at any density then we might want to also pass the current density the control is at to the command. So we are changing a control from mdpi to hdpi or back or to ldpi and so on.
> 
> Cheers
> 
> --
> M E R Goulding
> Software development services
> 
> mergExt - There's an external for that!
> 
> On 26/07/2012, at 7:18 PM, Scott Morrow <scott at elementarysoftware.com> wrote:
> 
>> I'm glad that this is staying on list for now as I'm working through trying to create a scalable app rather than ones with different fixed layouts.
>> 
>> Besides scaling the rect of objects, what other properties will likely need consideration?
>> A few that I'm puzzling over at the moment…
>> 
>> textSize
>> margins
>> lineSize
>> roundRadius
>> 
>> GraphicEffects
>> dropShadow: probably not all properties… spread, size, distance (opacity?)
>> innerShadow
>> outerGlow
>> innerGlow
>> 
>> Gradient
>> 
>> 
>> --
>> Scott Morrow
>> 
>> Elementary Software
>> (Now with 20% less chalk dust!)
>> web       http://elementarysoftware.com/
>> email     scott at elementarysoftware.com
>> ------------------------------------------------------
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Jul 25, 2012, at 5:17 PM, Monte Goulding wrote:
>> 
>>> OK Scott, should we continue on list or move off. It might be good to continue on list for a while to see who's keen to be involved.
>>> 
>>> Continuing to think out loud on this. One thing we want to be able to do is work in whatever density we like and then have everything still scale right. So what about the framework mainstack has a density property. On mobile this is worked out during preOpenStack and on desktop it would default to mdpi but be settable so  you can use whatever you want. This is independent of stack size and the setprop handler would cause the controls on the current card to resize.
>>> 
>>> One important thing to consider is inventing a cool non-developer specific acronym and prefix for this thing ;-) My hope is it can handle more than just this one issue. Thinks like preferences come to mind.
>>> 
>>> My vote is for mafia - Mobile App Framework with Interface Adaptation ;-)
>>> 
>>> --
>>> 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 at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode