Background Long IDs

[Brian Milby]

@Mark, same as before.  If the card has been visited then it starts with
group, if not it starts with bkgnd.

@Richard, probably more than you asked, but this is the project in a
nutshell...

The end goal is to enable a binary stack to have the scripts within tracked
via GitHub.  A closely related goal is to enable editing of said scripts
via an external editor.  Script only stacks are not the way that I want to
go for these projects (they are distributed as stacks and used within the
IDE as plugins).  I've got import/export working and a directory watcher
that will start an import when a file is updated.  Unlike lcVCS, this does
not attempt to do anything with tracking the other parts of the stack, just
the scripts.

Part of each file that I export includes a header with a "Script"
declaration (so they are actually valid livecodescript files).  I also
include the long ID and long name in the header as a comment.  For
backgrounds, I list all cards that contain the background.  If the object
has a behavior, then that is listed.  Objects with a behavior and no script
are also exported for the header.  The idea is that from any script file,
you can easily know what other script files are in the message path.  The
files are named by stack, object type, and ID.  I'm using an MD5 hash of
the script (including the generated header) to detect in IDE script
changes.  I'm using file modification times to track external changes.
Eventually I'll probably start using IDE messages to know about script
changes within the IDE to trigger updates.  I'll also connect the open
stack and save stack messages.

Due to the need to have a consistent file name, I decided to code my own
handler to return my version of a long name/ID for backgrounds.  I have to
detect groups that don't have a name set (since I then need to use the
ID).  I already know that the ID is for a background when I'm building the
long ID so that one was easy.  When I get to where I need the long name, I
look at the first word of the long ID and go from there (if it isn't bkgnd,
then just have the engine return it).

The exporter does a diff for each export to allow for tracking of changes
without using Git (one file per export).  My thought there is more of a
short history so I can see what I changed between saves.  It is also a kind
of safety net to allow me to back track if something didn't import like I
thought it should.

I'm sure an inevitable "why" would be asked, so I'll try answer that now.
In the IDE, the list of open stacks includes all script only stacks as
well.  If I scriptify a plugin that doesn't use "rev" named stacks, then
every object now shows as a user stack.  I can't see how having dozens or
hundreds of entries in the stack list would be good for performance.  So,
the first reason is to have text file versions of the scripts without
adding to the IDE list of open stacks.  The second reason is mentioned
above - distribution.  Having all of the code self-contained in a single
file makes moving it around much easier (this is for stacks, not compiled
applications).

I am close to being able to let others look at the project.  Initially it
will just tackle a single mainstack, but eventually I want to use it as a
plugin that can watch any number of stacks.  My intent is to put this up on
GitHub - where the scripts will be easily viewable online but the actual
stack will be a single file download.

Thanks,
Brian

On Sun, May 6, 2018 at 1:55 PM Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Brian Milby wrote:
>
>  > I'm working on a script exporter...
>
> What do you do with the exported scripts?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   ____________________________________________________________________
>   Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>