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