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
____________________________________________________________________
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
