My Journey... Resolution Independent Control library.

[Ralph DiMola]

I got LC 1 year ago for no other use than mobile. Very quickly I saw the LC
light and am using it as a replacement for VB6, but I digress.

When the multiple resolutions and rotation reality hit me.....
I first tried just to resize and re-position controls by a factor calculated
from resizestack message (newWidth,newHeight,oldWidth,oldHeight). This of
course introduced precision errors. This was very easy to see in the IDE by
just grabbing a corner and changing the size of a card. This worked for a
customer mobile demo with 1 resize and no rotation enabled.

Then I dropped all app development and started writing a Resolution
Independent Control library. If I had the LC knowledge at the time to
implement a UI like the one that Chip and Ken previewed I would have done
it. Very impressive guys!!!!!!! And I may be using yours in the future.

But alas I went a different direction.

As Bob points out below a percent type approach was what I went with.

I had these requirements:

1 card per screen
1 set of images, but the ability to use multiple images if needed for
exceptions.
All resolutions and aspect ratios.
Ability to change control layout (or not) based on screen orientation,
resolution or aspect ratio
Align controls with pixel precision.
Easy initial layout.
Not only resize the control but the text as well.
Resize text by.... best fit, scaling best fit, percent of IDE size, scaling
percent of IDE size.
Aspect ratio locking by X or Y.
Vertical centering of text.
Work for both mobile and desktop
Be a library stack
Images are of sufficient quality to be scaled.

Handle controls....
Images
Single line text Fields
Multi line text fields
Buttons
Button labels
Button icons with zoom in/out
Menu and tabbed controls. With the same text resizing options
Groups
Stamping controls in a group n across by z down
Stamping of any collection of controls n across by z down


 It is implemented with call(s) to my library from a switch statement
structure cased by card name in the preopencard and resizestack handlers in
the stack script.  Each call places 1 or more controls on a card. There are
several calls per card as you could imagine. Calls are a bit clunky but
quite fast once I got used to it. The calls have some advantages also. This
makes different layouts defined by orientation/resolution/stack aspect
ratios easy, just a switch statement away. A controls position/size is
defined by a percent to each side of the bounding box. The rect of the
bounding box is the edge of the card or the inside/outside edges of other
controls. This makes putting controls inside other controls easy. Seeing
that this is just a bunch of calls, the initial layout of a card is just
spit balling. The actual positions won't happen until the calls are tested
from the message box or by grabbing the corner of the card and changing the
size and watch everything click into position. This way if you set a control
to align 10% from the left, then all controls with a 10% left margin from
the same edge will align perfectly. Edges have infinite length. If you have
radio buttons then all the options will be spaced out evenly (or not).

We all seem to be doing a lot of work for something that could have been
handled in the engine. It would be nice if the mother ship could tell us
physical size of the device even if it was just phone/tablet/TV.

I'm happy with my solution for now. It works and I never care about new
resolutions. New resolutions to me are just a..... so you don't say.

I am now changing PlaceControls from calls to a custom Property Set to keep
the cards layout with the card and have no coding in the stack. I can then
handle the preopencard and resizestack messages from the library stack.

What a year!

Ralph DiMola
IT Director
Evergreen Information Services
rdimola at evergreeninfo.net

-----Original Message-----
From: use-livecode-bounces at lists.runrev.com
[mailto:use-livecode-bounces at lists.runrev.com] On Behalf Of Bob Sneidar
Sent: Monday, July 30, 2012 1:54 PM
To: How to use LiveCode
Subject: Re: Preview of Resolution Independent Control library for RevMobile

Seems like the whole pixel coordinate system achilles heel is showing.
Better would be a percentage system, so that theoretically I can set the
topleft of a control to a percentage of the hv of the card. 

This really should be an engine change, but I suppose a library could be
developed for this purpose. I'll have to think about it. Off the top of my
head, it would seem to me to be better to start with the smallest res
supported as the baseline layout, then scale up. 

Bob


On Jul 28, 2012, at 1:49 PM, Monte Goulding wrote:

> For layout to play nicely with scaling it will need to place controls
relative to each other and window boundaries and not include any reference
to physical pixels without multiplying by a scaling factor. So if you want a
field to have 3 px padding from the edge of the card you need to use 3 *
scale. So I think unfortunately the layout lib would need to be dependent on
the scaling lib. It could just be a single global variable though.
> 
> Cheers
> 
> --
> M E R Goulding
> Software development services
> 
> mergExt - There's an external for that!
> 
> On 29/07/2012, at 5:23 AM, Thomas McGrath III <mcgrath3 at mac.com> wrote:
> 
>> I agree and would go as far as saying that these must remain separate
libraries.They should play well together.
> 
> _______________________________________________
> 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