Richard Gaskin ambassador at
Sun May 3 13:58:30 EDT 2020

J. Landman Gay wrote:

 > On 5/2/20 8:20 PM, Richard Gaskin via use-livecode wrote:
 >> LiveCode is nearly unmatched for making desktop apps, but for
 >> mobile development there are so many unfinished edges it's barely
 >> a contender for anyone not already heavily invested in LiveCode
 >> from desktop work.
 >> It would be reassuring if the LC team could share with us their
 >> plan to finish their mobile implementation, to deliver a user
 >> experience on par with its best-of-breed desktop workflows.
 > That's what widgets are for.

Are they?

Widgets are great for specialized functionality not in the box.  But 
crafting custom widgets should not be seen as a replacement for 
essential common GUI elements.

Will you be solving your field display issue by writing your own text 
engine from scratch in a lower-level scripting language?

Should I tell that forum user that LiveCode doesn't provide common GUI 
essentials out-of-the-box?

Show of hands: how many of you would be using LiveCode today if the 
desktop editions required you to write your own common GUI controls from 

 > There are native fields and buttons, though some are still
 > missing, but not enough people are writing them. And unfortunately,
 > mobile GUIs change often enough on both Android and iOS that the
 > native buttons aren't so native any more.

If/when this goes in the engine, it could be handled as it is on the 
desktop, with hooks into the host OS renderer.  Write once, render anywhere.

But at the moment, at a minimum the team could do what so many of us 
have done: write a library that walks through LC-native controls on the 
card and makes appropriate replacements/additions where needed for mobile.

When the script sees a group or field with scrollbars, it turns the 
scrollbars off so they're not visible and automatically creates the 
mobile-native scoller region to match it.

When the script sees a checkbox, it hides that and instantiates a 
mobile-native Boolean selector.

When the script sees an editable field, it hides that and creates an 
editable field matching those properties in its place.

Pinch-to-zoom on images becomes a property, so those interactions invoke 
a good-but-difficult-to-find-buried-in-the-forums-script to handle that 
(the Lesson on that is woefully incorrect).

In each case, message handlers route mobile-native messages to their 
LC-native counterparts.  This lets you script using LC objects without 
having to type out control defs in code like you're a C programmer from 
1993.  And it lets you enjoy one of the finest benefits of The xTalk 
Way: blurring the line between development and runtime so you spend more 
time developing your app in the environment designed for developing.

This won't handle all possible circumstances, but will remove the most 
serious pain points from at least 80% of LC's uniquely odd mobile 
development workflows.

This could be done today.  It could have been done many years ago.  Many 
of us have been replicating this for years.

That would reduce the most common pain points, but still wouldn't 
address your need to scroll field text whose formatted height exceeds 

For that we need some engine work, to finally be done with the 
frankly-bizarre requirement that a perfectly good field needs to be 
wrapped inside of a group just to scroll smoothly.

We don't need that strange and unpredictable extra step on the desktop, 
and that we need it on mobile is not a feature, it's a bug, a 
shortcoming that I hope the engine team has a plan to address.

LiveCode on the desktop is flippin' awesome.  LiveCode on mobile can be 
every bit as awesome, and needs to be if it's to remain relevant in a 
world of simpler competitors.

The current workflow requirements undo the otherwise-powerful benefits 
of using LC on mobile for many newcomers.

  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  Ambassador at      

More information about the use-livecode mailing list