Converting scripts in stacks to script only stack behaviors

Ali Lloyd ali.lloyd at livecode.com
Sun Feb 5 13:22:42 EST 2017


Heh, I somehow missed the para where you made this comment already Brahma!
Sorry.

On Sun, Feb 5, 2017 at 6:21 PM Ali Lloyd <ali.lloyd at livecode.com> wrote:

> On the subject of building UI from script, I generally think it boils down
> to whether you already have a good resizeStack handler implemented.  If you
> do, you've done all the hard work already - you can just create all the
> objects with their required properties before the card opens and delete
> them when it closes, and your resizeStack does the rest of the placement
> work.
>
> Obviously this is a bit trickier if you have a lot of fields prepopulated
> with text, or groups with more complicated structure where it's not so easy
> to tease out the scripts into a behavior.
>
>
> On Sun, Feb 5, 2017 at 6:03 PM Sannyasin Brahmanathaswami via use-livecode
> <use-livecode at lists.runrev.com> wrote:
>
> Trevor, thanks for that intro to the new tools in LC9
>
>
> I'm already using libraries and behaviors extensively, but still find my
> self build LC stack binaries with a full stack script or, quite often,  95%
> of the code in the card script (if the UI can all be done on a single card)
>
> The other day I was thinking 'gee, why not just move this card script out
> to a behavior and assign it to the card."  been mulling this over for a few
> days, the the work flow for making this transition seemed onerous, but LC9
> will make it soooo easy!
>
> Our new app, SivaSiva, is being done with GIT and this is the first time
> working with GIT for something like this… for web and RevIgniter, GIT make
> obvious sense, since the whole environment is text files from the ground up.
>
> But now, with the new app, we have this mix of text only scripts and
> binary *.livecode stacks.
>
> So this leads to two more interesting avenue of adventure/explorations
>
> 1) we are already hitting GIT conflicts with the main stack of the project
> because if one developer needs to add some stack files, or wants to change
> a standalone setting for testing a build on a device, the IDE of course
> requires a Save… so now this stack must be either stashed (assuming you
> don’t need the changes) or committed.. and we hit a conflict later that is
> not so easily resolved.
>
> 2) building UI from script: every now and the notion passes by that
> perhaps building UI from script has advantages of  the LC WSIWIG model. I
> was  intrigued in your to see in the background in sublime text, you had a
> handler that built some of the UI.  perhaps all of it for that dialog box?
> So the question then becomes when, where and why do we make a decision to
> go the route to build UI by script? I guess the one obvious answer is that
> you want to put the UI under git control so that we have, as you put it
> "fine-grained control over changes, edits, history" etc.
>
> I wonder if there are other criteria besides that. Possibly building UI be
> script may be better suited to responsive design, since, in the end, if you
> want responsive geometry, you will end up writing those scripts anyway.
> The only thing missing being the default init props for the control (which
> we normally would create in the IDE) so one must as well "create button"
> and set the default init buttons in the script. Actually it would be pretty
> easy to create the button in WSIWIG and have a small tool to write out the
> initial props that you could then turn into a script.
>
> But this should probably be different thread.  I'm sure HQ has solved
> moved of these issues, but we may need to wait until LC9 is unveiled before
> we get the full picture from the mother ship, until then… I "muddle along"
>
> Brahmanathaswami
>
>
>
> _______________________________________________
> 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
>
>



More information about the use-livecode mailing list