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