Preview of Resolution Independent Control library for RevMobile

Monte Goulding monte at
Thu Jul 26 08:27:56 EDT 2012

> First off, I would like to say there are a few things which are paramount
> for me in any resizer library I would use. Please know these are only my
> observations and requirements.

Great. Id like it to meet as many peoples requirements and get as much input as possible :-)
> 1. Needs to be unlocked and editable my me. If not, then I won't even look
> at it. We all know the problems with MobGUI and the subsequent lack of
> support and stranded users. Simple fact is I just can't provide my clients
> with code I can't maintain.

Definitely. I was proposing this be FOSS with input from whoever is interested. I was not thinking it would be in mergExt or anything although if it was it would be unlocked anyway as any LC scripts I put in there will be. I've even offered to do a special price on source access if required but haven't had any interest ;-)
> 2. It needs to be as simple and easy to maintain as possible. And in
> keeping with the simplicity theme, it needs to execute as fast as possible
> in the least amount of readable code. I'm not a fan of frontscripts and
> find they can get in the way in all sorts of ways, so I'd prefer staying
> with libraries and passing messages.

Ok, could be a little tricker to ensure the job gets done of its not in a front script but that's ok. I think for the resizing we just need preopencard.
> 3. It should be easy to implement and without much fanfare. Most of my
> mobile projects need to be completed in weeks, not months, so trying to
> work with a complex framework just doesn't fit my projects. I certainly
> understand others have different timescales and may be more interested in
> more elaborate frameworks.

What I've started with so far is easy. I would propose a plugin be part of it which would create a vanilla project.
> 4. It needs to fit within my workflow. I use a Harness app for both Android
> and iOS phones and tablets which acts as a "player" for stacks, which are
> then downloaded via a Dropbox URL. So, it's more difficult to add lots of
> other files, like interface images in the bundle. I would rather bring
> files down from the Internet, or SpitOut them on the first run.

What I'm proposing is a mainstack that loads a UI stack and any resources if required. It essentially does what you are doing already but from local files and I'm sure a slightly modified version of the framework could be made to do what you are doing and that way everyone else can do it too because it sounds great!
> 5. I think I can make a case that it's pretty much impossible in LC at this
> stage to identify dpi vs resolution needs if you're trying to go cross
> platform-- Android-iOS. Furthermore, as a designer, I can only imagine the
> possible nightmare involved in not having the exact right resolution images
> for different Android Layouts. I would suspect the carefully set margins
> and padding of one's design would get fairly screwed up. LC just doesn't
> work well with complex architectures and frameworks. Geometry Manager?
> Animation Manager? Ring any bells?

I'm not talking complex here. In fact I think it will be quite simple once we divide resizing for density from layout. Layout is handled in resize stack. It could be library scripts or just resize stack handlers doing that. Resizing for density is handled at preopencard if it hasn't been done yet for that card.

> 6. Lastly, if you tend to like to create skeuomorphic interface designs, as
> I do, then you pretty much know you have to work all your graphics out in
> Photoshop. So, for the most part there's no needing to worry about scalable
> *everything* in LC, as the images themselves scale quite well. So having a
> heavyweight library which tries to match each and every control attribute
> with the proper scaling algorithms, seems a bit overkill for me. Keeping
> things simpler, and lighter-- is better. For me.

Obviously that's not going to work for people like Scott who do their art in LC graphics. Can you see a way around that so we can all collaborate?



More information about the Use-livecode mailing list