revUp - Updates and news for the LiveCode community
Issue 145 | December 7th 2012 Contact the Editor | How to Contribute

Geometry 3.0: The Scaling Revolution
Have you ever dreamed of scaling your entire application in one click? You need to look at NativeGeometry 3...

By Damien Girard


Today, we are looking at a new kind of display: High DPI Screens. These screens allow beautiful definition on any computer, better text display, gorgeous images... The problem is that not all applications support them. Read on to find out how NativeGeometry can help you solve this problem in your application.

What is screen DPI and why you must consider it?
Before we start, what is DPI? Here is a definition:

DPI Stands for "Dots Per Inch." DPI is used to measure the resolution of an image both on screen and in print. As the name suggests, the DPI measures how many dots fit into a linear inch. Therefore, the higher the DPI, the more detail can be shown in an image.

So this means that the more DPI your screen has, the smaller the text will be if it is not zoomed. Windows Vista and X server on Linux allow users to set a custom DPI setting in order to make the text readable on all platform. On Mac OS X, the retina display automatically adapts and requires no tuning of applications.

But this DPI setting come at a price: The application must support it and must be able to "scale up" all its objects in order to look good with these big fonts!

DPI Bug at High Resolution

Figure: Sample application not fully supporting high DPI font settings (click image to zoom)

In future there will be more and more devices with many different DPI settings. Ffor example on Android already there are many possible DPI options. Add to this screens designed for people with visual problems and we have a huge variety of monitors to support.

So, the question is: With LiveCode how can I support different DPI settings easily?

NativeGeometry 3 introduces Scaling Features to LiveCode
NativeGeometry 3 enables you to "Code once, run everywhere, on all screens!"

You develop your application once at the standard DPI setting (without any scaling), then when you execute your application, no matter what the screen DPI is, the application will look great for the end user. NativeGeometry takes care of the scaling.

Different DPI

Figure: Two LiveCode applications at two different scale setting (click image to zoom)

The screenshot above shows you NativeGeometry 3 in action. With just the slider you are able to zoom up/down the livecode application without having to change anything.

Develop Once, run your App on all Desktop and Mobile OS's
NativeGeometry 3 has improved support of font and screen DPI detection. With only a few scripts in your mainstack you will be able to create good looking applications for all platforms without any headache!

Sample Windows/Mac

Sample application on Windows 7 and MacOS X (click image to zoom)

NativeGeometry 3 also adds support for Mobile:

Mobile

Sample mobile application on non-retina iPhone and Retina iPhone (click image to zoom)

As you can see, the application is automatically scaled to the high DPI screen of the iPhone retina. NativeGeometry can scale all objects and has been designed to work on mobile platforms.

Develop Once, Translate your App to all Languages
You were considering creating a multi-language application? NativeGeometry 2 was already your friend, but NativeGeometry 3 is even better.

In your preopencard handler you can update all the text on your card, then simply pass the preopencard handler. NativeGeometry will resize all its objects to fit them to their content.

Translation

Figure: Two languages, French and English.

As you see on the screenshot above, the French strings are longer than English. NativeGeometry resize the objects automatically.

New Object Dependencies Resolver
In order to have the scaling feature working perfectly, the object dependency solver in NativeGeometry 3 has been rewritten. The resizing operation is faster, and geometry relations compiling is instant. This allows you to work with more objects with incredible speed.

But why does NativeGeometry have a dependencies solver? The answer is simple: objects that depend on the card/stack edge or on nothing have to be resized first so that objects that depend on them can be resized too. Without NativeGeometry, you have to take care of this in your resizeStack script, otherwise you can get some very unexpected results when you resize the stack. With NativeGeometry, this is automatic.

How to Try?
You can try NativeGeometry 3 for free, the restriction is just a nag screen displaying from time to time within the IDE and inside your compiled application.

To purchase NativeGeometry, visit the RunRev Marketplace or upgrade from NativeGeometry 2 within your LiveCode account. It is with your support that I continue to develop those LiveCode extensions!

Note for NativeGeometry 2 users: NativeGeometry modified the geometry database format. NativeGeometry 3 will upgrade the database to the new format automatically. To revert back to NativeGeometry 2 format, you need to install NativeGeometry 2.2 which supports the downgrading of the database format.

About the Author

Damien Girard started programming at 7. He began writing LiveCode solutions at 12. Now he works for a company as an embedded Linux expert and C/C++/C#/LiveCode programmer. He continues to release extensions for LiveCode in his spare time.

Main Menu

What's New


Buy DVDs plus Simulcast 70% off