A little Levure-oriented question

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

A little Levure-oriented question

Clarence Martin via use-livecode
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.

Graham
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
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 <
[hidden email]> wrote:

> On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
> [hidden email]> 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
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Script Only stacks make versioning and multiuser development environments possible, at least from the coding aspect of things. They cannot be password protected however, nor can they have properties, so even a faceless application which needed to avail these features would still need a UI stack. Also, objects whose code is unique and never changes would not benefit from a versioning system or as a behavior. It's probably simpler just to code the object. My 2¢

Bob S


> On Feb 20, 2018, at 15:15 , Graham Samuel via use-livecode <[hidden email]> 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.
>
> Graham

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
AFA the password protection goes, the traditional stack is only required
when you _distribute_ the app.  You do not need to store it that way.  When
you build a Levure app, it automatically creates a binary stack, installs
the code, and password protects it.  You get the best of both worlds:  On
your system and in your VCS you have the script as straight text, and when
you distribute it, you get encrypted.
You are absolutely correct that scripts that never change don't benefit
from version control (and really, for short scripts, the value of version
control is also limited).  In this case, the reason why I like to have this
code stored in SOS's is because if I ever accidentally change one of these
scripts, my git tool will flag it as a change that has to be committed.

On Tue, Feb 20, 2018 at 7:40 PM, Bob Sneidar via use-livecode <
[hidden email]> wrote:

> Script Only stacks make versioning and multiuser development environments
> possible, at least from the coding aspect of things. They cannot be
> password protected however, nor can they have properties, so even a
> faceless application which needed to avail these features would still need
> a UI stack. Also, objects whose code is unique and never changes would not
> benefit from a versioning system or as a behavior. It's probably simpler
> just to code the object. My 2¢
>
> Bob S
>
>
> > On Feb 20, 2018, at 15:15 , Graham Samuel via use-livecode <
> [hidden email]> 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.
> >
> > Graham
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
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 <[hidden email]> 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 <
> [hidden email]> wrote:
>
>> On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
>> [hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
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 <
[hidden email]> 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 <
> [hidden email]> 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 <
> > [hidden email]> wrote:
> >
> >> On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
> >> [hidden email]> 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
> >> [hidden email]
> >> 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
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
But if there’s no code in the UI stack, how do the handlers in the SOS know what object has invoked them? I mean of course you can work out the caller, but it’s much easier to say

on mouseUp
doSomethingJustForMe(myCoordinates
end mouseUp

than working it all out later, isn’t it?

Doubtless this is a dumb question, but I told you I was confused.

Graham

> On 21 Feb 2018, at 18:59, Mike Kerner via use-livecode <[hidden email]> wrote:
>
> 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 <
> [hidden email]> 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 <
>> [hidden email]> 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 <
>>> [hidden email]> wrote:
>>>
>>>> On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
>>>> [hidden email]> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
"me" in a behavior script is the calling object.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
The engine is what actually starts execution of the SOS - the engine knows who called. “me” is a keyword set up by the engine. In a behavior script it is the caller. Is this what you were wondering about or did I misunderstand?
.Jerry

> On Feb 21, 2018, at 10:58 AM, Graham Samuel via use-livecode <[hidden email]> wrote:
>
> But if there’s no code in the UI stack, how do the handlers in the SOS know what object has invoked them? I mean of course you can work out the caller, but it’s much easier to say
>
> on mouseUp
> doSomethingJustForMe(myCoordinates
> end mouseUp
>
> than working it all out later, isn’t it?



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 2/21/18 12:58 PM, Graham Samuel via use-livecode wrote:
> But if there’s no code in the UI stack, how do the handlers in the SOS know what object has invoked them?

A behavior acts as though every object with the assigned behavior has
that script copied into itself. That means that "me" always refers to
the object with the behavior, and each instance of the behavior keeps
its own separate script local variables. Without a behavior, you'd need
to put a mouseUp handler that calls "doSomething" into each button, and
doSomthing would live in a card or stack script. Then doSomething would
have to get the name of the target to know the caller, and also keep
track of any local variables independently.

I'm working with a project that uses a lot of script-only stacks. It
uses a combination of embedded ("normal") scripts and SOS. Handlers that
only apply to a single object or card are usually written into the stack
or control as usual. Handlers that are used in more than one place are
moved to SOS either as behaviors or libraries. Libraries work like
stacks in use, behaviors can be shared among different objects. For
example, we have a behavior that creates and manages a native scroller
on mobile. Whenever we need a native scroller for a field, we assign
that SOS as a behavior of the field. The field itself has no script, the
behavior does it all.

 From what I've read so far here, you don't actually have to convert
everything to script-only stacks. You can convert some, or none, or all.
I believe Trevor said that you can use other functions outside of the
script management features -- for example, built-in functions that
compile the app or do auto-update, etc. Your point about not needing SOS
for a single developer is, I think, correct. But even if you're the only
one working on a stack, you may still want to track changes and updates
in a versioning system. Whatever you want to track, you'd convert to a
SOS because versioning systems work only with text files.

I haven't made the move myself either, but I'm interested in what is
possible so I've been following this thread. Don't feel bad about
asking, some of us are lurking.


--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On Wed, Feb 21, 2018 at 12:58 PM, Graham Samuel via use-livecode <
[hidden email]> wrote:

> But if there’s no code in the UI stack, how do the handlers in the SOS
> know what object has invoked them? I mean of course you can work out the
> caller, but it’s much easier to say
>
> on mouseUp
> doSomethingJustForMe(myCoordinates
> end mouseUp
>
> than working it all out later, isn’t it?
>
> Doubtless this is a dumb question, but I told you I was confused.
>

Not dumb at all. You are right that attaching the mouseUp handler to the
object that receives the mouse click is easier. Where you are mistaken is
in your belief that the UI stack does contain code and the logic is not
handled in a library. The UI stack does in fact have code, it just happens
to be in behaviors that are script only stacks. Let me provide an example
of an About window which would be organized in the following file system
structure in Levure:

app/
  ui/
    about/
      about.livecode
      behaviors/
        card.livecodescript

Now assume that the about.livecode stack file has a field that shows the
version information and a button named “Acknowledgements” that opens a PDF
when you click on it.

The card.livecodescript is a SOS that is assigned to the behavior property
of card 1 in the about.livecode stack file. Any code in that
card.livecodescript SOS acts as if it is the actual code assigned to the
script property of card 1. The code just happens to live outside of
about.livecode.

So card.livecodescript can contain our primary handlers that do all of the
work:

```
on preOpenCard
  ShowVersion
end preOpenCard


command ShowVersion
  # Display current version in field
  …
end ShowVersion


command uiShowAcknowledgements
  # Launch PDF
  …
end uiShowAcknowledgements
```

The “Acknowledgements” button can now call the `uiShowAcknowledgements`
handler in the card script (which is really the card.livecodescript SOS
that is assigned to the behavior of the card).

```
on mouseUp
  uiShowAcknowledgements
end mouseUp
```

In the example above, the code in the button is actually assigned to the
script property of the “Acknowledgements” button and is part of the
about.livecode stack file. Not in some behavior. The code for the card
script is stored in a SOS that is assigned to the behavior property of the
card. This code lives outside of about.livecode stack file.

Now, you could move the “Acknowledgements” button code into a SOS as well.
In that case you would create a new SOS, move the script in the button to
the SOS, and then assign the SOS to the behavior property of the button.
Here is what the new file structure would look like:

app/
  ui/
    about/
      about.livecode
      behaviors/
        card.livecodescript
        acknowledgement_button.livecodescript

You wouldn’t have to change the `on mouseUp` code at all because behavior
scripts act as if they are the actual script of the control they are
assigned to.

Hopefully that clarifies things a little bit.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
The target.

Bob S


> On Feb 21, 2018, at 10:58 , Graham Samuel via use-livecode <[hidden email]> wrote:
>
> But if there’s no code in the UI stack, how do the handlers in the SOS know what object has invoked them?

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
It’s very late here, so a brief reply to a brief reply. I know about ‘the target’. Believe it or not I also know about behaviours and can use them. But if I have a Big Green Button in my UI, I want a handler which does something if and only if the Big Green Button is clicked on. Obviously in my SOS I can have some ‘universal’ code that says something like

if the target is “bigGreenButton” then
 do something related only to this particular object
 …

But isn’t that just making the whole thing more complicated than it need be?

Maybe I will understand this clearly in the morning - who knows?

Graham

> On 21 Feb 2018, at 22:33, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> The target.
>
> Bob S
>
>
>> On Feb 21, 2018, at 10:58 , Graham Samuel via use-livecode <[hidden email]> wrote:
>>
>> But if there’s no code in the UI stack, how do the handlers in the SOS know what object has invoked them?
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
Graham,
You don't need universal code to make this happen.  What Trevor was talking
about yesterday was that he likes using universal handlers in card scripts
(or card behaviors in this case).  For your example all you have to do is
take the script of the big green button, make it a SOS, and assign that SOS
as the behavior of the big green button.  You don't have to have a behavior
shared between a bunch of objects.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
I'm not a purist, I'd put the handler in the big green button. Especially
if it's short. There are no hard rules about this stuff.

I suppose I'll have to dodge flying fruit now.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



On February 21, 2018 6:29:52 PM Graham Samuel via use-livecode
<[hidden email]> wrote:

> It’s very late here, so a brief reply to a brief reply. I know about ‘the
> target’. Believe it or not I also know about behaviours and can use them.
> But if I have a Big Green Button in my UI, I want a handler which does
> something if and only if the Big Green Button is clicked on. Obviously in
> my SOS I can have some ‘universal’ code that says something like
>
> if the target is “bigGreenButton” then
>  do something related only to this particular object
>  …
>
> But isn’t that just making the whole thing more complicated than it need be?
>
> Maybe I will understand this clearly in the morning - who knows?
>
> Graham
>
>> On 21 Feb 2018, at 22:33, Bob Sneidar via use-livecode
>> <[hidden email]> wrote:
>>
>> The target.
>>
>> Bob S
>>
>>
>>> On Feb 21, 2018, at 10:58 , Graham Samuel via use-livecode
>>> <[hidden email]> wrote:
>>>
>>> But if there’s no code in the UI stack, how do the handlers in the SOS know
>>> what object has invoked them?
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
Me too.
.Jerry

> On Feb 21, 2018, at 9:20 PM, J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> I'm not a purist, I'd put the handler in the big green button. Especially if it's short. There are no hard rules about this stuff.
>
> I suppose I'll have to dodge flying fruit now.



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Jacque always dishes out common sense IMHO. Thanks for that. I would shield you from the flying fruit if I could.

I guess my heretical thinking is based on two ideas:

1. Setting the behavior of an object (my Big Green Button) looks just like scripting it to me: I mean for this to work, the object has to be qualified by a reference to something outside its local environment: OK, it’s not exactly code, but it seems to me philosophically similar. So the UI stack is tied, however lightly, to the SOS undergrowth.

2. When I’ve used behaviors myself, it’s to allow essentially the same script to be used for many objects, with the extremely useful ability to hang on to the local context: I once used behaviors for cells ina spreadsheet-like display, for example - whereas in my current example, I proposed that the Big Green Button was unique and wouldn’t want to share its primary handler with anyone else (though of course it would probably use some common library routines in any complicated set up). If in my example there was a Big Red Button, it would have an entirely different function from the Green one, so there would be no room for the shared code a behavior provides. So the use of behaviors in this kind of setup looks kind of forced to me. But perhaps I am overestimating the extent to which behaviors come into the picture.

Changing the subject a bit, I once wrote a very simple DC circuit simulator, in which there were different components like a light bulb, a motor, a buzzer etc. When the user ‘switched’ the circuit on (by clicking on an object representing a switch), the program sent the same message - “applyVoltage”-  to each object. Each object had its own applyVoltage handler (method, in O-O parlance) for reacting to the circuit going live, so the bulb lit up, the motor rotated etc. This is kind of the inverse of the behavior idea - this is the same message being sent to multiple objects rather than multiple objects using the same script. I wonder how a Levure-framed app would deal with such a structure. Perhaps it wouldn’t notice at all.

Graham

PS My UK spell checker **really** wants behavior to be behaviour, but this is not among its synonyms, regrettably.



> On 22 Feb 2018, at 06:20, J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> I'm not a purist, I'd put the handler in the big green button. Especially if it's short. There are no hard rules about this stuff.
>
> I suppose I'll have to dodge flying fruit now.
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
>
> On February 21, 2018 6:29:52 PM Graham Samuel via use-livecode <[hidden email]> wrote:
>
>> It’s very late here, so a brief reply to a brief reply. I know about ‘the target’. Believe it or not I also know about behaviours and can use them. But if I have a Big Green Button in my UI, I want a handler which does something if and only if the Big Green Button is clicked on. Obviously in my SOS I can have some ‘universal’ code that says something like
>>
>> if the target is “bigGreenButton” then
>> do something related only to this particular object
>> …
>>
>> But isn’t that just making the whole thing more complicated than it need be?
>>
>> Maybe I will understand this clearly in the morning - who knows?
>>
>> Graham
>>
>>> On 21 Feb 2018, at 22:33, Bob Sneidar via use-livecode <[hidden email]> wrote:
>>>
>>> The target.
>>>
>>> Bob S
>>>
>>>
>>>> On Feb 21, 2018, at 10:58 , Graham Samuel via use-livecode <[hidden email]> wrote:
>>>>
>>>> But if there’s no code in the UI stack, how do the handlers in the SOS know what object has invoked them?
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
On Thu, Feb 22, 2018 at 7:25 AM, Graham Samuel via use-livecode <
[hidden email]> wrote:

> 2. When I’ve used behaviors myself, it’s to allow essentially the same
> script to be used for many objects, with the extremely useful ability to
> hang on to the local context: I once used behaviors for cells ina
> spreadsheet-like display, for example - whereas in my current example, I
> proposed that the Big Green Button was unique and wouldn’t want to share
> its primary handler with anyone else (though of course it would probably
> use some common library routines in any complicated set up). If in my
> example there was a Big Red Button, it would have an entirely different
> function from the Green one, so there would be no room for the shared code
> a behavior provides. So the use of behaviors in this kind of setup looks
> kind of forced to me. But perhaps I am overestimating the extent to which
> behaviors come into the picture.
>

Whether or not it is forced depends on your goals.

I have two goals - manage my app using git and be able to edit all scripts
in an external text editor (I use Sublime Text). If I don’t move the button
behavior out into an SOS then it won’t play well in my text editor. As an
example, two days ago I was cleaning out unused code in a project. In
Sublime Text I searched my project for calls to a handler. The handler was
called from a couple of button scripts inside of a binary LiveCode stack
file (I had not converted every script in the stack to a SOS behavior). In
the search results in Sublime Text I couldn’t see what the actual script
was, just that a binary file had a reference to the string I was searching
for. I want to be able to read the script. Also, if I end up changing the
button script (I’ve been known to rename handlers if I want to clarify what
it does) then I want my git history to show me exactly what changed. If I
save the script as part of a binary stack I can’t see what changed. If I
store the script in an SOS then I can.


> Changing the subject a bit, I once wrote a very simple DC circuit
> simulator, in which there were different components like a light bulb, a
> motor, a buzzer etc. When the user ‘switched’ the circuit on (by clicking
> on an object representing a switch), the program sent the same message -
> “applyVoltage”-  to each object. Each object had its own applyVoltage
> handler (method, in O-O parlance) for reacting to the circuit going live,
> so the bulb lit up, the motor rotated etc. This is kind of the inverse of
> the behavior idea - this is the same message being sent to multiple objects
> rather than multiple objects using the same script. I wonder how a
> Levure-framed app would deal with such a structure. Perhaps it wouldn’t
> notice at all.


Whether or not you use Levure would have no effect on how you solve this
particular problem. Levure encourages the developer to organize your stacks
using the file system and to organize stacks within folders based on how
they are used (window, library, behavior, etc.). One benefit of following
Levure’s suggestion is that your app becomes more VCS-friendly. How you
organize objects on your cards or architect solutions to problems such as
this falls outside the scope of Levure.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: A little Levure-oriented question

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
If you watch Trevor's youtube videos you will see he makes allowance for this. No need to behaviorize a script that will never change, and only applies to one object. You could, but no one says you have to. In fact, if you don't have a need for versioning, don't use a foreign text editor, don't share common code between multiple objects, and don't need the features a git repository can give you, then you don't need behaviors. I didn't start using them until I got tired of editing code in identical buttons in 15 different modules every time I had to change something. I don't particularly need Levure either for most of what it does, but I really like Sublime Text, and would like to use that if I could.

Bob S


> On Feb 21, 2018, at 16:27 , Graham Samuel via use-livecode <[hidden email]> wrote:
>
> It’s very late here, so a brief reply to a brief reply. I know about ‘the target’. Believe it or not I also know about behaviours and can use them. But if I have a Big Green Button in my UI, I want a handler which does something if and only if the Big Green Button is clicked on. Obviously in my SOS I can have some ‘universal’ code that says something like
>
> if the target is “bigGreenButton” then
> do something related only to this particular object
> …
>
> But isn’t that just making the whole thing more complicated than it need be?
>
> Maybe I will understand this clearly in the morning - who knows?
>
> Graham

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12