YES . . . What he said! > On Mar 29, 2021, at 8:55 AM, Richard Gaskin via use-livecode > <use-livecode@lists.runrev.com> wrote: > > TL/DR: > > We don't need a generic player. > > What we need is an updated Standalone Builder, to provide more complete > tooling and better guidance for building a modern standalone. > > > > ------------- more complete version ---------------------------- > > > Background > ---------- > > This thread, and many others like it, didn't start with a desire for a > player. That was merely a response to the challenges of building standalones. > > Building standalones is the point of LiveCode, the culmination of everything > in LC's user experience. > > And it's become a pain point for most, early-prohibitive for some. > > OS changes are of course not LC's fault. But they are LC's opportunity, if > the company wants to maintain its place as the easiest solution for making > apps. > > > > The Last Great Deployment Change > -------------------------------- > > Back in the early days, the IDE's Standalone Builder didn't provide any > support for document associations, creator codes, or other essentials we now > take for granted. It was expected we'd open some dev tool from Apple > (ResEdit) to set those up. > > LC Ltd recognized those steps were cumbersome, and often error-prone where > they were being done at all. > > So they took the time to completely redesign the Standalone Builder to > include support for nearly every detail apps need for solid deployment. > > > > The Next Great Deployment Change > -------------------------------- > > Many if not most deployment tooling required by OSes are command-line apps, > lending themselves well to being called from another program, such as LC's > Standalone Builder. > > Automate everything possible. > > And where a step can't be automated, guidance and be provided, such as a > direct link right in the SB's UI to the necessary steps for completing the > process, laid out with sufficient clarity and detail to allow the user to > complete the build with confidence. > > If a standalone building step is essential, it needs to be handled in the > Standalone Builder. > > Use direct automation where possible, or a direct link in the UI to > step-by-step instructions needed to complete the task. > > > > The Business Case > ----------------- > As we've seen here and many other threads like it from time to time, as long > as building a standalone in LC is characterized by confusion and dread, > people will seek alternatives. > > Any alternative either compromises LC's revenue model (based as it is around > standalone licensing), or eliminates it (if LC is just as hard to use as > anything else, why not use anything else?). > > No option provides as much return on investment as focusing on updating the > Standalone Builder to be as simple and graceful as it can possibly be. > > LC has a strong advantage with its language, made a nearly unbeatable with > its integrated GUI object model. > > Bring deployment up to par with the rest of the experience, and LC has a > chance for a good life ahead, slowing attrition rates while accelerating > growth. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.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
_______________________________________________ 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
