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 ScreenSteps www.screensteps.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode