Request to makers of add-ons

Richard Gaskin ambassador at fourthworld.com
Sat Mar 22 10:08:52 EDT 2014


James Hale wrote:

 > I really enjoy looking at software and appreciating the work
 > the authors put in to their products.
 > The same goes for all the helpful add-ons that are written for
 > Livecode.
 > I have quite a few and really appreciate their utility.
 > But I have one request for authors of add-ons that require the
 > installation of a library or "engine" in our projects.
 > Please put a check in your demo/help/install stacks that check for
 > the presence of the library BEFORE trying to load another copy.

That's an excellent idea.

This raises a question for an option that may be useful to add to the 
Standalone Builder:

Currently the SB allows us to specify external stacks, and at build time 
it'll copy those into a folder accompanying the app.

On OS X those files are copied into the bundle, but on Windows and Linux 
it puts them into a separate folder alongside the app.

If you're not using externals you wouldn't otherwise need that folder - 
why not - at least optionally - just copy the stacks into the stack file 
that becomes the standalone?

If the SB had an option for that we'd have a few benefits:

- Users of a given library wouldn't need multiple copies installed into 
their own mainstacks.  This not only solves your problem, but the 
additional problem of opening two different stacks which contain the 
same copied substack, along with simply saving space.

- One copy means one update to that stack file in the Plugins folder 
brings every subsequent build forward automatically.

- It obviates the need for an extra folder for the standalone, allowing 
you to deliver a single executable file if you like (provided you're not 
already using externals or other separate files).

Hmmmm....

The more I think about this, the more I realize this doesn't need to be 
in the SB at all, it could be a plugin that handles the savingStandalone 
message in a frontScript, examining a custom property in the mainstack 
(that it could provide a convenient UI to set) for a list of stack files 
to include, and then copy those in as needed.

Anyone have time to make such a tool?  If not I'll add it to my to-do list.



 > There seems to be a bug in either the way Livecode handles this
 > situation or how the add-on is responding to it.
 > LC throws up a warning of an existing stack of that name (the
 > library) but gets stuck in an endless loop trying to resolve it
 > regardless of one's response to the warning ( be it purge, save or
 > cancel.)
 > I can only assume that LC does its thing but is then thrown back by
 > the add-on trying to do its thing.

As much as I appreciate the simplicity of being able to address stacks 
by short name, stack name conflicts have been a problem for many of us 
from time to time, including yours truly.

I submitted an enhancement request to address this some time ago, but 
the current behavior is so ingrained in the engine that no clear way to 
resolve that has yet emerged:
<http://quality.runrev.com/show_bug.cgi?id=1061>

At a minimum, the error handling for stack name conflicts in the IDE 
needs to be improved.  If you have a specific recipe for any such 
conflicts that are particularly troublesome, please file a bug report 
against it.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys





More information about the use-livecode mailing list