ambassador at fourthworld.com
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.
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
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
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.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode