On Mon, Mar 29, 2021 at 3:56 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Here's the bottom of the post you were replying to:
>       One suitable solution in the box is all that's needed,
>       with the option for folks to turn it off if they prefer
>       using any other of the infinite variety of all possible
>       solutions.
> So yeah, I don't much mind whether we call them "hooks" or "options" or
> even "doilies" as long as it supports the core need right out of the
> box, without penalizing deeply-experienced professionals with specific
> tool preferences.

We agree that LiveCode should include a sensible baseline for building a
standalone. We also agree that they shouldn't try to write solutions for
all possible ways that someone may need to distribute a standalone. My 2
cents is that LiveCode should provide a way for 3rd parties to expand on
what happens when a standalone is being built. This is more than just
turning off an option. Turning off an option would introduce an absence of
behavior. I'm suggesting the addition of behavior that can occur during key
points of the standalone building process.

Perhaps all use cases can adequately be handled with the messages that are
already sent once when a standalone builder finishes (e.g. savingStandalone
and standaloneSaved).

But, perhaps the standalone building process would be better served with
additional, more granular callbacks, and maybe those callbacks are sent to
a target other than the stack being saved. That is what I would like to be
considered when modernizing the Standalone Builder.

Trevor DeVore
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to