Crazy script-only stack question
MikeKerner at roadrunner.com
Mon Jan 22 17:44:26 EST 2018
We are starting to get a bit afield, but as long as we are, the issues with
the layout editor bring us to the same place as the issues with the script
editor: Why exert so much effort on the editor instead of writing plugins
for third-party OSS editors, that have a much larger user base and
developers who are actively working on them (and designers developing
interface elements and themes)?
On Mon, Jan 22, 2018 at 3:56 PM, Sannyasin Brahmanathaswami via
use-livecode <use-livecode at lists.runrev.com> wrote:
> Not barking up the wrong tree at all, with multi-stack apps very much in
> the wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_)
> not having and a RCS for the binary stacks themselves is a nuisance. But
> your 5 liner doesn't solve that either.
> But how does creating a stack and setting it's script to a text file
> different from adding a stack to your framework and then setting the
> behavior of that stack to the text only script?
> Or put another way, what advantage would it have over the behavior of the
> stack? And since your newly created stack has no controls, those would all
> need to be created by script and this is exactly what LiveCode provides:
> WSIWG layout environment (albeit needs a lot of work to get to 2018
> standards )
> A case can be made for treating the binary stacks as a "view" Typically
> there is a split in the team between design and code. This is also
> happening universally where designers are doing UI/UX prototypes in
> InVision Or Zeplin.. (no code) and push these over to the code team.
> We have such stacks in the SivaSivaApp. where there is almost no code in
> the stack at all. We use "the target" …in the text only behavior stacks…
> this is working pretty well as once the eye candy and UX is locked in, we
> are not touching that too much, if anyone is, it's usually just one person,
> so pulling and pushing the binary from GIT is not that big a deal… conflict
> wise… of course if some others on the team *do* want to touch the UI, then
> it gets messy
> On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via
> use-livecode" <use-livecode-bounces at lists.runrev.com on behalf of
> use-livecode at lists.runrev.com> wrote:
> Is there any reason script-only stacks had to be implemented in the
> Is there any reason *not* to implement their equivalent in about five
> of code in the mainstack of a project? i.e.,
> on loadTextStack tFilePath
> put url ("file:/" & tFilePath) into tStackData
> put line 1 of tStackData into tStackName
> create invisible stack tStackName
> set the script of stack tStackName to line 2 to -1 of tStackData
> send "openStack" to stack tStackName
> end loadTextStack
> This would immediately fix the issue of chained behaviors, and allow
> the incremental implementation of a far richer format for text-based
> storage, leading to gains in project-definition source control.
> Given that Bug 10275 <http://quality.livecode.com/
> show_bug.cgi?id=10275> is
> over five years and several versions old, am I barking up a tree with
> or making sense?
> with no clue,
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
and did a little diving.
And God said, "This is good."
More information about the use-livecode