Re: A little Levure-oriented question

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> The only way I can see for that to be a bad thing is if it became the
> new and ONLY way to develop in Livecode. So long as they are options,
> I do not see what all the fuss is about.

Amen, brother.  Options are liberating, requirements are limiting.

My only fuss is to make sure the breadth of options remains wide, and 
that the simplest are invitingly presented as the entry point for new 
scripters.


Those who identify as pro devs looking to save time on GUIs can find 
their way beyond a beginner's guidance, as long as they're motivated to 
do so by having seen great examples (don't get me started about what 
I've seen in the Android app store).


But the beginner knows nothing, so we want to tell the most inviting 
tale, to guide them into a story of the shortest path they've ever 
imagined between conceiving of an app and handing a standalone of it to 
a friend.


This is a story LiveCode can tell uniquely well, provided we aim to be 
good storytellers.


--
 Richard Gaskin
 Fourth World Systems


___
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

Re: A little Levure-oriented question

[Bob Sneidar via use-livecode]

The only way I can see for that to be a bad thing is if it became the new and 
ONLY way to develop in Livecode. So long as they are options, I do not see what 
all the fuss is about. 

Bob S


> On Feb 22, 2018, at 13:38 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Good rant.  I had a similar reflection this morning reading a forum post
> in which Mark Wieder was waxing about the benefits of declaring
> variables.  It got me thinking:
> 
>  Variable declaration
> + coded descriptions of objects rather than laying them out visually
> + separation of code from UI
> = an ever more C-like workflow.
> 
> If these practices were the norm back when many of us got started, we
> might have just taken up C.  Or if we prefer more typing, Pascal. :)


___
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

Re: A little Levure-oriented question

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:
> Richard wrote:
>> Mike Kerner wrote:
>>> The ST integration is one of the things that is really slick about
>>> Levure.
>>
>> "ST"?
>>...
>> "Space Telescope"?  "SuperTux"?  "Starship Trooper"?
>>
>> Any of those integrations would be awesome.
>
> Integration for Starship Troopers is still in beta.

I'm anxious to get my hands on it, as I'll need for for my new widget 
library, Perpetual Changelog. ;)



Graham Samuel wrote:
> Just read in Trevor’s reply to me - it’s Sublime Text.

Ah, right. Of course.  Thanks.  I hear it's a nice editor.

UDAs can be confusing.


> (Rant-style observation: I see really that what the whole Levure thing
> is doing is moving towards a more industrial-scale development context
> for LiveCode. This is great if you need it. In the past I worked on
> (for my sins, even tried to manage) software development projects with
> more than 50 participants. In those days we had pretty lousy tools for
> version control etc. I do appreciate that such things have moved on
> and are an essential part of modern team development. In the past, LC
> and its predecessors, including especially HyperCard, were conceived
> as one-man-band type of development tools, I think. There are still a
> lot of people like that out there, and I admit to being one. This is
> not to say we’re all hobbyists - some of us are certainly developing
> stuff that we believe will be seen as professional by paying users,
> but we do not operate in that industrial context. All development
> needs discipline, sure, but individual developers do have to consider
> the cost in labour of committing to a new and different way of doing
> things, IMHO. Rant ends)

Good rant.  I had a similar reflection this morning reading a forum post 
in which Mark Wieder was waxing about the benefits of declaring 
variables.  It got me thinking:


  Variable declaration
+ coded descriptions of objects rather than laying them out visually
+ separation of code from UI
= an ever more C-like workflow.

If these practices were the norm back when many of us got started, we 
might have just taken up C.  Or if we prefer more typing, Pascal. :)


Today, the logical choice would be JavaScript, no longer just the only 
language in browsers but also great on servers and even some native 
mobile and desktop app packagers.  Many of the benefits of C but with 
the sort of live coding scripters enjoy.


While there are some nice things unique to xTalks as a language family 
(esp. the under-appreciated value of having GUI objects as native 
language elements rather than tossed in after the fact from completely 
separate third-party frameworks as though making applications is somehow 
an afterthought), the real allure of The xTalk Way is the whole gestalt, 
including the secret charm of binary stack files, and how it shapes a 
very different way of working.


You can make something useful, ship that one file to someone else, and 
they have something useful - no assembly, no compilation process, no 
folders full of tiny files to sift through.  Just make, share, enjoy a 
single simple file.


We still have that.  And I hope we never lose that as an option.

But now we also have other options available to us, which open up many 
more doors than could be possible without.


So whatever process you use, if you're having fun and your users are 
having fun, keep doing it.


And if you need to bring in other developers, now you can more easily 
than before.


And if your clients demand managing the code base in Git, no problem.

The simplicity of HyperCard will never be matched, but not so much 
because of design, but because needs have changed since 1987.  Computing 
went from being a fringe hobby to achieving multi-device ubiquity.  Our 
collective knowledge of computing systems, and our expectations of what 
we want from them, have expanded along the way.


With the world of options opening up across all of software development, 
and in our LiveCode world along with it, we can dream a wider range of 
more interesting dreams than ever before.


If I have any concern at all it's for the UX, the tender loving care 
that can only come from eyes unjaded by years of staring at C compilers, 
to keep the LC experience as clean and inviting as it can be for the 
next generation of xTalkers.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: A little Levure-oriented question

[Trevor DeVore via use-livecode]

On Thu, Feb 22, 2018 at 12:11 PM, Graham Samuel via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Just read in Trevor’s reply to me - it’s Sublime Text. No, I’d never heard
> of it either. Myself, I have been happy editing with what comes with LC,
> which probably goes to show something a bit negative about me.
>

Why would it be a negative? If it works for your needs then that is great.
You can get all of your work done in a single location.


> (Rant-style observation: I see really that what the whole Levure thing is
> doing is moving towards a more industrial-scale development context for
> LiveCode.


FWIW I am the only developer that regularly contributes to my apps built on
top of Levure. That won’t always be the case and when the time comes it
will be easy to add people. But version control isn’t synonymous with
industrial-scale. Nor is using folders to organize your Livecode project
files rather than a monolithic binary stack.

Using version control provides quality control in my workflow and makes it
easier to fix mistakes. For example:

* No code change ever gets into my project without being reviewed at least
twice. Once while I’m writing it, and a second time when I’m committing the
changes I’ve made to Git. I’ve caught many mistakes through this review
process.
* If I happen to make a change in my software that unintentionally breaks
something I can review the Git commit and see all of the changes I made. I
can then easily reverse those changes.
* I have a complete audit trail of all changes made so I can see where I
might have introduced issues.

In addition I can work on multiple new features at once, yet easily deploy
a hot fix if a customer finds something that needs fixing right away.

Version control isn’t for everybody and may not be worth the hassle for
you. There is nothing wrong with that. But I wouldn’t dismiss it as being
something that only teams use.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.com
___
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

Re: A little Levure-oriented question

[Bob Sneidar via use-livecode]

Integration for Starship Troppers is still in beta. 

Bob S


> On Feb 22, 2018, at 09:09 , Richard Gaskin via use-livecode 
>  wrote:
> 
> "Space Telescope"?  "SuperTux"?  "Starship Trooper"?


___
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

Re: A little Levure-oriented question

[Graham Samuel via use-livecode]

Just read in Trevor’s reply to me - it’s Sublime Text. No, I’d never heard of 
it either. Myself, I have been happy editing with what comes with LC, which 
probably goes to show something a bit negative about me.

(Rant-style observation: I see really that what the whole Levure thing is doing 
is moving towards a more industrial-scale development context for LiveCode. 
This is great if you need it. In the past I worked on (for my sins, even tried 
to manage) software development projects with more than 50 participants. In 
those days we had pretty lousy tools for version control etc. I do appreciate 
that such things have moved on and are an essential part of modern team 
development. In the past, LC and its predecessors, including especially 
HyperCard, were conceived as one-man-band type of development tools, I think. 
There are still a lot of people like that out there, and I admit to being one. 
This is not to say we’re all hobbyists - some of us are certainly developing 
stuff that we believe will be seen as professional by paying users, but we do 
not operate in that industrial context. All development needs discipline, sure, 
but individual developers do have to consider the cost in labour of committing 
to a new and different way of doing things, IMHO. Rant ends)

Back to the grindstone.

Graham

> On 22 Feb 2018, at 18:09, Richard Gaskin via use-livecode 
>  wrote:
> 
> Mike Kerner wrote:
> > The ST integration is one of the things that is really slick about
> > Levure.
> 
> "ST"?
> 
> A quick Google search brought up this page of 173 possible meanings for that 
> acronym, so I feel I'm getting close.
> https://www.acronymfinder.com/ST.html
> 
> "Space Telescope"?  "SuperTux"?  "Starship Trooper"?
> 
> Any of those integrations would be awesome.
> 
> Hint?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> 
> 
> ___
> 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


___
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

Re: A little Levure-oriented question

[Graham Samuel via use-livecode]

Thanks for your patience, Trevor. I will stop tyre-kicking now and decide 
whether or not my particular project work merits taking the Levure plunge!

Graham

> On 22 Feb 2018, at 15:56, Trevor DeVore via use-livecode 
>  wrote:
> 
> On Thu, Feb 22, 2018 at 7:25 AM, Graham Samuel via use-livecode <
> use-livecode@lists.runrev.com> 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
> 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


___
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

Re: A little Levure-oriented question

[Richard Gaskin via use-livecode]

Mike Kerner wrote:
> The ST integration is one of the things that is really slick about
> Levure.

"ST"?

A quick Google search brought up this page of 173 possible meanings for 
that acronym, so I feel I'm getting close.

https://www.acronymfinder.com/ST.html

"Space Telescope"?  "SuperTux"?  "Starship Trooper"?

Any of those integrations would be awesome.

Hint?

--
 Richard Gaskin
 Fourth World Systems


___
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

Re: A little Levure-oriented question

[Mike Kerner via use-livecode]

The ST integration is one of the things that is really slick about Levure.
Atom is a more polished editor, but you can configure ST to send a packet
to LC when you save an SOS.  Levure projects open a socket to listen for
that signal, and when it receives the signal, reloads the script you just
saved, so your edits are live.
Now if I could just get the indent rules working better in ST (or Atom) I'd
be even happier.
___
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

Re: A little Levure-oriented question

[Bob Sneidar 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 
>  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
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

Re: A little Levure-oriented question

[Trevor DeVore via use-livecode]

On Thu, Feb 22, 2018 at 7:25 AM, Graham Samuel via use-livecode <
use-livecode@lists.runrev.com> 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
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

Re: A little Levure-oriented question

[Graham Samuel 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 
>  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 | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> 
> On February 21, 2018 6:29:52 PM Graham Samuel via use-livecode 
>  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 
>>>  wrote:
>>> 
>>> The target.
>>> 
>>> Bob S
>>> 
>>> 
 On Feb 21, 2018, at 10:58 , 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?
>>> 
>>> ___
>>> 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
>> 
>> 
>> ___
>> 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
> 
> 
> 
> ___
> 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


___
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

Re: A little Levure-oriented question

[Jerry Jensen via use-livecode]

Me too.
.Jerry

> On Feb 21, 2018, at 9:20 PM, J. Landman Gay via use-livecode 
>  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
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

Re: A little Levure-oriented question

[J. Landman Gay 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 | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On February 21, 2018 6:29:52 PM Graham Samuel via use-livecode 
 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 
 wrote:


The target.

Bob S


On Feb 21, 2018, at 10:58 , 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?


___
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



___
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




___
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

Re: A little Levure-oriented question

[Mike Kerner 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
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

Re: A little Levure-oriented question

[Graham Samuel 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 
>  wrote:
> 
> The target. 
> 
> Bob S
> 
> 
>> On Feb 21, 2018, at 10:58 , 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?
> 
> ___
> 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


___
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

Re: A little Levure-oriented question

[Jerry Jensen 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 
>  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
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

Re: A little Levure-oriented question

[Graham Samuel 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 
>  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 <
> use-livecode@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@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@lists.runrev.com> wrote:
>>> 
 On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
 use-livecode@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@lists.runrev.com
 Please visit this url to 

Re: A little Levure-oriented question

[J. Landman Gay 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 | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
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

Re: A little Levure-oriented question

[Bob Sneidar via use-livecode]

The target. 

Bob S


> On Feb 21, 2018, at 10:58 , 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?

___
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

Re: A little Levure-oriented question

[Mike Kerner via use-livecode]

"me" in a behavior script is the calling object.
___
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

Re: A little Levure-oriented question

[Trevor DeVore via use-livecode]

On Wed, Feb 21, 2018 at 12:58 PM, Graham Samuel via use-livecode <
use-livecode@lists.runrev.com> 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
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

Re: A little Levure-oriented question

[Mike Kerner 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 <
use-livecode@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@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@lists.runrev.com> wrote:
> >
> >> On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
> >> use-livecode@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@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 

Re: A little Levure-oriented question

[Graham Samuel 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 
>  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@lists.runrev.com> wrote:
> 
>> On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
>> use-livecode@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@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


___
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

Re: A little Levure-oriented question

[Mike Kerner 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 <
use-livecode@lists.runrev.com> 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 <
> use-livecode@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.
> >
> > Graham
>
> ___
> 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

Re: A little Levure-oriented question

[Bob Sneidar 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 
>  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
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

Re: A little Levure-oriented question

[Mike Kerner 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 <
use-livecode@lists.runrev.com> wrote:

> On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
> use-livecode@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@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

Re: A little Levure-oriented question

[Trevor DeVore via use-livecode]

On Tue, Feb 20, 2018 at 5:15 PM, Graham Samuel via use-livecode <
use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

A little Levure-oriented question

[Graham Samuel 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
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