Geoff, Since Trevor didn't answer the Levure question, The way he suggested structuring the projects was putting the ui elements and their behaviors into /ui/stackName (and then the behaviors for that stack into /ui/stackName/behaviors/). As for naming the stacks, Scriptifier does it one (long) way in an attempt to make all the names unique. Trevor had suggested objectType<sp>objectName<sp>"behavior", but of course there is no reason why you would would have to be held to that.
It's not that you can't have scripts all over the Levure project, because you will with libraries, components, etc. but those aren't the major PITA, and that isn't what you're trying to address with Navigator. SO, if I was going to convert a stack automagically, I would want to 1) make a copy of the stackfile, placing it in the /ui/stackname folder and work on the copy 2) pull the various behaviors and put them in the /ui/stackfile/behaviors folder From there, we can argue a lot about the structure of the behaviors folder. On the one hand, if you keep everything in there together, then you can kind-of use the names to keep everything straight, because as long as you don't change the names of the SOS's, it doesn't matter if you move the objects they are tied to from one card to another. It's just that the /behaviors folder can become the storage for hundreds of SOS's. On the other, it might be good to give the developer an option to have subfolders for each card, but as soon as they move an object from one card to another you have a gigantic mess of the developer wanting the SOS's to move, but that will break the references, etc. I'm glad you're working on this! Now I can stop thinking about working on it and go do something else. On Mon, Jan 22, 2018 at 6:38 AM, Trevor DeVore via use-livecode < use-livecode@lists.runrev.com> wrote: > On Mon, Jan 22, 2018 at 12:20 AM Geoff Canyon via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > It occurs to me that this isn't as much of a problem as I thought -- any > > button being converted to a stack is highly unlikely to have an openstack > > handler already in it, and therefore it would be safe to add one and > > include setting the behavior of the script-only stack to the appropriate > > stack up the chain. If there were already an openstack handler in the > > chain, then the conversion process could stop at that point, or perhaps > log > > the error to the user. Unless I'm missing something? > > > Geoff, > > Keep in mind that script only stacks that are loaded into memory by the > engine because they are referenced in the stackfiles of another stack won’t > be sent any messages. > > http://quality.livecode.com/show_bug.cgi?id=18223 > > You have to complete the behavior chain in the openStack handler of the > stack that is being opened. I think in your case you would process the > openStack message in the stack you are setting the stackFiles on. > > Trevor DeVore > ScreenSteps > > > > _______________________________________________ > 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
