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 mak
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
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 Troo
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
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
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 m
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 <
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"? "St
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
sav
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
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 be
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 obje
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.
___
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.hype
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
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
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-livecod
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
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" alway
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@lis
"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
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
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
quot
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
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
yo
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.
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
substac
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’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
29 matches
Mail list logo
