Helping newcomers anticipate that standalones can't save to themselves

[Richard Gaskin]

Vaughn Clement wrote:

 > Hi Richard
 >
 > Although I have not seen this occur in stacks I've created, I would
 > like to better understand where you are going with this topic? Are
 > you starting a new way to address specific issues with LiveCode, or
 > suggesting changes to the IDE?

That's a good question, and to be honest I'm not really sure, just 
exploring options.

I kinda like the idea of a runtime emulator, but even if we could build 
such a thing that can account for the many platform-specific things it 
would need to be useful, we're still left with the same need:

If a person is able to know that they need to run a tool to discover the 
implications of not being able to save to a standalone, the existing 
Standalone Builder provides that.  The trick is being able to know that 
this sort of evaluation has to be done at all.

Extending the documentation might be useful, but only to the degree that 
any new additions will be read.

We could add all sorts of additional tutorials and such, but this issue 
is already described in a very bold callout on the User Guide page that 
discusses standalones (p 299).  If users aren't reading the primary 
source of information on using LiveCode, what assurances can we have 
that they'll discover any other discussion of this in some separate 
tutorial?


Mike's very inventive, and I like where he's going with this:

 > How about going the other direction and fixing the behavior?
 >
 > Technically, any standalone CAN edit itself, anyway, but there are
 > all sorts of things that might be able to be done with ancillary
 > files to store changes/updates.  When the standalone is going to
 > set something, it checks the file (like a settings file), first.

One of the challenges with such an approach is that people use LiveCode 
in a wide variety of ways, and in a few cases may rely on data being 
cleared when the standalone is exited.

So maybe such a behavior could be limited to attempting to use a save 
command on a standalone, in which it automatically clones that stack? 
But then where would it be saved?  How would it know whether it should 
be in the Documents folder, or Prefs, or App Support, or some other place?

Taking a broader view, for most apps it's not desirable to save UI 
elements at all, populating the UI with data stored externally instead, 
so when you deploy upgrades the new UI can display older data without 
having to worry about the old UI.  And for separate data storage there 
are many options, from text files to custom properties to XML to JSON to 
databases and more - which one is the right fit for the application at hand?

Currently these are decisions we make, and once we understand that OSes 
don't allow executables to write to themselves we design with this in 
mind, and often enjoy the flexibility of having so many different 
options for managing persistence.

In our local user group we kicked around some ideas for handling this, 
but it didn't take long until what we were leaning toward was a sort of 
framework.  But as useful as frameworks can be they can also be 
limiting, and require learning even more to be able to do productive 
work since we have to learn both LiveCode and the specific ways LiveCode 
is used within the framework.


It's an odd problem, in that it's simple enough to accommodate once the 
need is known, but difficult to know it's needed in advance.

I used to think that this expectation that standalones might be able to 
save to themselves was limited to those with HyperCard experience, since 
AFAIK Mac Classic (by virtue of its resource fork) was the only OS in 
popular use that ever allowed this.  And given that both HC and Mac 
Classic were killed off more than a decade ago, I would have expected 
this issue to come up ever less often since.

Yet somehow even among young people, who've never used HC and in a world 
where they've never seen any application save to itself, find themselves 
with the expectation that this should be doable.

Not sure how that expectation happens, or how to prevent it, but it 
comes up just often enough that I think it may be worth trying.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com