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@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 > > BR > > On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via > use-livecode" <use-livecode-boun...@lists.runrev.com on behalf of > use-livecode@lists.runrev.com> wrote: > > Is there any reason script-only stacks had to be implemented in the > engine? > > Is there any reason *not* to implement their equivalent in about five > lines > 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 > for > the incremental implementation of a far richer format for text-based > stack > 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 > this, > or making sense? > > with no clue, > > Geoff > > _______________________________________________ > 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 > -- 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." _______________________________________________ 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