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.br...@livecode.com> wrote: > On 2015-08-29 23:05, Monte Goulding wrote: > >> On 29 Aug 2015, at 10:22 pm, Peter TB Brett <peter.br...@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.br...@livecode.com> > LiveCode Open Source Team > > LiveCode on reddit! <https://reddit.com/r/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 _______________________________________________ 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