Trevor DeVore lists at
Thu May 5 09:48:17 EDT 2011

On Wed, May 4, 2011 at 3:35 PM, J. Landman Gay <jacque at>wrote:
> Just to play devil's advocate: I find that GLX is overkill for almost all
> the apps I create. I prefer to use only code that actually applies to my
> project. I have my own set of common handlers and functions that I insert as
> needed, which keeps my apps small and compact.

Hi Jacque,

How long have you been developing with X-Talk languages? It's a rhetorical
question as I know that you are one of the top LiveCode programmers here.
But I would make the case that the only reason you have these common
handlers and know how to slim things down is because of your years of
experience. Even if there were a common library that was freely available,
new users would still not have enough knowledge to know where exactly to use
them for application development. I believe this will remain the case for as
long as LiveCode remains stack based as opposed to application or project

> Don't get me wrong, GLX is excellent for what it does, but for me it isn't
> the best way or even the preferred way most of the time. If we had an
> "officially-sactioned" framework it would tend to become the default, to the
> exclusion of simpler methods where they are more appropriate.

There doesn't necessarily need to be an official framework but it is
definitely in everybody's best interest for at least one to exist that is
really well documented and provides everything the developer needs to get
started. The goal should be that the developer only has to focus on code
specific to their application. As the developer becomes more experienced
they can decide if they want something simpler.

> GLX is one choice, and ideally there would be others to choose from, or
> none at all.

I believe that having "none at all" is one of the major reasons the platform
isn't more popular. LiveCode is an incredible tool for developing in. It has
a very steep learning curve for app development. For developers looking at
LiveCode they only see what they see when they open the IDE. If you are
trying to develop an application there is essentially nothing to help you
get started in designing what goes on behind the scenes. This is a glaring
problem for people coming from other environments.

The final argument against an official framework is that people would tend
> to use it without understanding the underlying concepts involved.

I don't think there is anything wrong with that. Do all of the longtime
LiveCode developers understand what LiveCode is doing when it renders
graphics to the screen or displays text in a field? No. And we shouldn't
have to. For most of us there will always be things going on behind the
scenes that we don't fully understand. We may learn more about particular
areas as we progress. There are other areas that we will never understand,
nor will we care. Trying to understand everything that goes into making an
application right from the beginning is asking too much IMO. I would venture
to guess that most who try LiveCode just give up.

> Once you have those, building an app isn't really that difficult.

Coming to understand the underlying concepts involved is no small journey,
at least it wasn't for me. When I first started using LiveCode I really
struggled with how to design an application. I had a number of false starts
and nearly gave up a few times. All that after having spent months trying to
decide what LiveCode was. It took me a few applications and a few years
before I really felt like I had a handle on everything involved.

I wouldn't argue that the GLX Application Framework needs to be THE
framework that everyone uses but it is my contribution to help solve a
problem that I think is a major stumbling block. It is far from perfect and
not fully documented but it is something. If more people were involved in
the development/documentation effort it would be much better.

Trevor DeVore
Blue Mango Learning Systems

LiveCode Resources for Developers:

Get SQL Yoga as part of the Omegabundle for LiveCode 2011: Save 85% on
essential tools for LiveCode development -

More information about the use-livecode mailing list