Just to clarify, I didn’t really mean to suggest that there was a plan - it’s just that a lot of the creative energy around LC and its development seems to be going away from this as if it were bad, basically because it’s hard to do version control on binary stacks, as far as I can see. I do understand that separating UI elements and code is good practice, but for many types of projects it can be taken too far, I think. I am all for libraries, for example, but I don’t want to strip my stacks right down to a graphical shell. LC and its predecessors aren’t really designed for that - they are essentially systems where interaction with graphic elements via a message path is the key idea, which means that there **must** be some level of scripting at the UI level. To try to suggest that good practice takes that away completely, or as near completely as ingenuity can make it, seems to me a distortion of an really excellent model of interaction - but that’s just my opinion, of course.
Graham > On 22 Jan 2019, at 01:25, Curry Kenworthy via use-livecode > <use-livecode@lists.runrev.com> wrote: > > > but it’s not OK if this is at the expense of the kind of user > > who doesn’t want to distort the way LC works, for example by > > deprecating stacks that contain both scripts and UI elements > > I wasn't aware of a plan or push to deprecate those - I don't follow all > threads, but I emphatically hope not; bad idea! I want LC stacks to remain > stacks. Easy to use and learn, self-contained, smart. _______________________________________________ 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
