GLXFramework

Pete pete at mollysrevenge.com
Thu May 5 13:30:55 EDT 2011


As a relatively new user (couple of years), I wholeheartedly agree with the
framework concept.  LC touts itself as being easy to use because of its
English syntax but the reality is that its learning curve is extremely
steep. I'm pretty sure there's a large number of people out there who have
simply given up on it for that reason and that's sad, because LC really is a
pretty remarkable development tool.

One of Trevor's key phrases is "the developer only has to focus on
code specific to their application".  That's the crux of the matter to me.
 I don't want to have to spend time on implementing standard
edit functions like cut, copy, paste, select all, undo even though once I've
made my version of that code I can reuse it.  I want that functionality to
just be there so I can use the small amount of brain power I have on
figuring out how to implement the logic of my application.

If there's ever a project to develop some sort of open source framework for
LC, count me in!

Pete
Molly's Revenge <http://www.mollysrevenge.com>




On Thu, May 5, 2011 at 6:48 AM, Trevor DeVore <lists at mangomultimedia.com>wrote:

> On Wed, May 4, 2011 at 3:35 PM, J. Landman Gay <jacque at hyperactivesw.com
> >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
> based.
>
>
> > 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: http://livecode.bluemangolearning.com
>
> Get SQL Yoga as part of the Omegabundle for LiveCode 2011: Save 85% on
> essential tools for LiveCode development - omegabundle.com.
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>



More information about the use-livecode mailing list