A little Levure-oriented question

Mike Kerner MikeKerner at roadrunner.com
Wed Feb 21 12:59:09 EST 2018


You do not have to have a single line of code in the .rev/.livecode file.
You can have behaviors assigned to each object, card, and the stack.  Those
behaviors would be assigned to script-only stack files (.livecodescript).
The first line of a SOS is the word "script", then a name, enclosed in
quotes.  That name does not have to be related to anything, or have any
meaning.  After that first line would be the code/handlers, etc.
If you like, you can consolidate your code into only a few SOS's, or you
can have an SOS as the behavior for every single object.

On Wed, Feb 21, 2018 at 11:46 AM, Graham Samuel via use-livecode <
use-livecode at lists.runrev.com> wrote:

> OK, i’m a bit confused. If we look at a non-faceless application, then the
> user will be interacting with it via the UI. This means that stuff like
> clicking and dragging has to be dealt with. I see that this can all be done
> by a library that works out where the ‘mouseUp’ or whatever came from and
> then handles what is needed to be done and sent back to the user, but can
> there really be no code at all in the stack the user sees? What about a
> game-like interface, where the movement of objects relative to one another
> is something that has to be captured? I suppose what I’m saying is that if
> the essence of the app is the interaction between the objects the user
> sees, then abstracting the objects’ behaviour away from the primary
> interface only has the merit that it’s better for version control, doesn’t
> it? Or am I seeing it all wrong?
>
> Graham
>
> > On 21 Feb 2018, at 01:04, Mike Kerner via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> >
> > You can move as much or as little as you like.  I prefer to move
> everything
> > and use an external text editor whenever I want to edit code.  The .rev
> or
> > .livecode stack file for me, then has multiple cards with the layouts and
> > the objects, but no code in it.  I also have taken to removing all
> > substacks and making them separate, especially since in many cases those
> > substacks are modules or libraries.  That makes version control of those
> > submodules and libraries far simpler for me.
> >
> > On Tue, Feb 20, 2018 at 6:43 PM, Trevor DeVore via use-livecode <
> > use-livecode at lists.runrev.com> wrote:
> >
> >> On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
> >> use-livecode at lists.runrev.com> wrote:
> >>
> >>> I’m following the Levure discussion and of course Trevor's
> pronouncements
> >>> with great interest. One thing strikes me - is there really a
> universally
> >>> understood meaning to the term “UI stack”? I do understand the concept
> of
> >>> separating the UI from the logic of an app, but any UI must contain
> >>> **some** logic, mustn’t it? In the LC world, by ‘logic’ of course I
> >> really
> >>> mean code. What level of coding is permissible to allow in a UI stack,
> do
> >>> people think? I have a feeling that some folks’ idea of this is going
> to
> >> be
> >>> very different from some others’. Perhaps there is an orthodoxy about
> >> this,
> >>> but I am not familiar with it.
> >>>
> >>
> >> In Levure a UI stack is just a stack that is used as a window to
> display a
> >> user interface to the user. In LiveCode the term stack is overloaded. It
> >> can be a library, a front script, a back script, or a stack that is
> >> actually displays to the user. Actually it can be both a stack that
> >> displays an interface to the user and a library/frontscript/
> backscript).
> >> So
> >> Levure encourages you to organize your stacks based on how they are
> used.
> >> In Levure a UI stack will be added to the list of stackFiles property of
> >> the main Levure app stack. This allows you to reference the stack by
> name
> >> (e.g. stack “MyStack”) without having to load all of the UI stacks into
> >> memory when the application starts up.
> >>
> >> My general rule is that I place all code that is specific to a specific
> UI
> >> stack in the behaviors attached to the stack, cards, and controls of
> that
> >> stack. Any code that is shared is pushed down into a library.
> >>
> >> The controls in my stacks have very little code. They simply call
> handlers
> >> that reside in the card or stack behaviors.
> >>
> >> --
> >> Trevor DeVore
> >> ScreenSteps
> >> www.screensteps.com
> >> _______________________________________________
> >> use-livecode mailing list
> >> use-livecode at 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 at 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 at 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."



More information about the Use-livecode mailing list