Script-only stacks [was: Re: Script Editor future]

[Ali Lloyd]

I agree that any scriptOnly property should be read-only, thus eliminating
any potential dire consequences. After all, you can easily lossily
scriptify a stack by creating a new script-only and setting the script to
another one.

Whilst I agree that the main use of script only stacks should be for
behaviors and libraries, in the IDE we are using script-only stacks as UI
as well - after all it is only a small additional step if you are using
resize handlers to also have the stack create the UI elements when it opens.

On Sat, Aug 29, 2015 at 11:24 PM Peter TB Brett <peter.brett at livecode.com>
wrote:

> On 2015-08-29 23:05, Monte Goulding wrote:
> >> On 29 Aug 2015, at 10:22 pm, Peter TB Brett <peter.brett at livecode.com>
> >> wrote:
> >>
> >> This looks like the sort of thing that's best off being looked at by
> >> Mark Waddingham.  Unfortunately my last day before my annual holiday
> >> is the day before he gets back from his annual holiday, so I'm not
> >> going to be able to bring this up with him for at least a couple of
> >> weeks.  Can I suggest that you e-mail him directly?
> >
> > I’ll just wait for Mark to get back. It’s a simple one but there’s
> > obviously dire consequences for your stack objects if you set the
> > scriptOnly to true so I’d like to get the nod before bothering. The
> > engine forum has gone fairly quiet lately but the original idea was we
> > would propose stuff we wanted to do then get the nod on syntax and
> > whether it would be accepted if we did it etc. It may be that script
> > only stacks are short term and the long term plan is not to have these
> > scripts be stacks but update start using, back|front script and
> > behavior to point to files rater than objects. Is that why they aren’t
> > documented?
>
> I *think* Mark will be back in the office on Monday, so he'll probably
> see this exchange
>
> At the moment I usually treat normal stacks and script-only stacks as
> totally different things.  I think of normal stacks as places for UI and
> trivial glue code, and script-only stacks as places for complex handler
> libraries and behaviours.  They have different filenames too (.livecode
> vs .livecodescript).  My instinct is that adding a way to switch a stack
> back and forth between normal and script-only isn't very intuitive, and
> could cause "dire consequences" as you suggest.  On the other hand,
> having a *read only* scriptOnly property (or some equivalent) sounds
> like it could be pretty useful.
>
> We *really* need documentation with more structure.  I can't remember
> how one tests what sort of object something is, and the dictionary isn't
> giving me any hints...
>
> >> Or just submit a PR on GitHub, that'll make sure it doesn't get
> >> forgotten about. ;-)
> >
> > I actually had some PRs that were forgotten about although I think
> > both of them have now or will in the future at least become irrelevant
> > because of widgets.
>
> Oops, sorry.  I shouldn't let these things slip through the cracks.
> It's a lot easier now that there's a defined process for accepting
> contributions!  The processes for community contributors and LiveCode
> employees are now pretty much the same -- the only two differences are
> that 1) we still can't accept binary stack changes directly (sorry :-/)
> and 2) employees don't have to sign the CLA.
>
> If you've got some PRs that have been overlooked about but which are
> still relevant, let me know and I'll try and make sure they get looked
> at...
>
>                                    Peter
>
> --
> Dr Peter Brett <peter.brett at livecode.com>
> LiveCode Open Source Team
>
> LiveCode on reddit! <https://reddit.com/r/livecode>
>
> _______________________________________________
> 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