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

AcceleraterRendering - when to turn off/on

[Sannyasin Brahmanathaswami via use-livecode]

Having a heck a time with our new app on android

One stack works fine.

But we are going one stack to another, (not in iOS) is a problem.

Seems to be subtle issues with one of the follow

(although on the surface they seem to be same)

1) it is better to

set the acceleratedRendering of this stack to false

-- on closeCard
-- on closeStack
-- on library stack, used to close one stack and one open another

Go window did not work, as it never gets the handler that set stack to 
landscape.

So it back to

go cardOrStackObject # e.g go "gems" (or this string) go card 3 of "gems"
wait 100 milliseconds with messages
close stack oStackName
wait 100 milliseconds with messages

"wait" is android issue. I don’t need it for iOS

2) The issue is the same with mobile controls.
When is a safe delete them?

-- on closeCard
-- on closeStack
-- on library stack, used to close one stack and one open another

BR


Svasti Astu, Be Well
Brahmanathaswami
www.himalayanacademy.com Get SivaSiva App 
Today--It's Free!

iOS: https://itunes.apple.com/us/app/sivasiva/id1271260502?mt=8
Android: 
https://play.google.com/store/apps/details?id=com.himalayanacademy.sivasiva
___
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

Just Checking in my posts made it

[Sannyasin Brahmanathaswami via use-livecode]

Checking

BR
___
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: libsodium on LiveCode?

[Brian Milby via use-livecode]

Here is a paragraph from scuttlebutt.nz which documents what I’m looking to
interface with:

In nacl both types of keys are used, signing keys are ed25519 keys, and
exchange keys are curve25519 keys. sign uses ed25519 keys, and scalarmult
takes curve25519. box takes two exchange keys, and then uses scalarmult
internally. There is also another function secretbox that just takes a
symmetric key, say the output of scalarmult.

So it is a bit more than just getting a key pair.

Thanks,
Brian
On Wed, Feb 21, 2018 at 4:58 PM Charles Warwick <
char...@techstrategies.com.au> wrote:

> What type of key do you need to generate?
>
> > On 21 Feb 2018, at 2:50 pm, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Had not seen the tsNet handler, but that is an RSA key. Scuttlebutt uses
> a
> > different key type. There are other useful things in the library. There
> is
> > some overlap, but enough different to make it worthy of an effort.
> >
> > I’ll need to take a look at the MS links.
> >
> > Hopefully the rest of today and tomorrow will go better!
> > On Tue, Feb 20, 2018 at 10:13 PM Monte Goulding via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >>
> >>
> >>> On 21 Feb 2018, at 2:57 pm, Brian Milby  wrote:
> >>>
> >>> Monte, you are awesome!
> >>
> >> Cheers! Not feeling so awesome today… been banging my head on something
> >> all day and getting nowhere :-(
> >>>
> >>> With your help I was able to generate a key pair using libSodium. That
> >> means that we are one huge step closer to asymmetric key generation and
> use
> >> within LC.
> >>
> >> Hmm… have you seen tsNetGenerateKey ?
> >>>
> >>> For each tool chain they provided a static and dynamic directory. The
> >> static just contained a .lib file. The dynamic contains 3 or 4 files.
> >> Starting at 140 a .pdb file is added. The latest one that works is v120.
> >>>
> >>> Thanks for the help!
> >>
> >> OK, I’m not sure why they aren’t working. The main thing I’d look for is
> >> if they are built to dynamic link to the CRT and you don’t have the
> >> corresponding version of MSVS or the redistributable packages installed.
> >> You could try installing this and then test 140
> >> https://www.microsoft.com/en-au/download/details.aspx?id=48145 <
> >> https://www.microsoft.com/en-au/download/details.aspx?id=48145>
> >>
> >> Cheers
> >>
> >> Monte
> >>
> >> ___
> >> 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: LiveCode Widget Factory

[prothero--- via use-livecode]

This is a wonderful development and should add tremendously to Livecode’s 
desirability as a development platform.

Bill P

William Prothero
http://es.earthednet.org

On Feb 21, 2018, at 2:56 PM, hh via use-livecode 
 wrote:

>> Todd F. wrote:
>> I have been in touch with a few people to get their ideas and needs,
>> but I wanted to reach out and check with the community.
>> At first, wehave decided to focus these for round one:
>> Basic Native UI elements, Native Maps  
> 
> Please start with *cross-platform-native* widgets for all of the UI elements 
> in
> the LC Tools (which all are "basic").
> 
> Alone reaching that single target before 2021 would be a little wonder.
> 
> I admire what is possible already now with LCB. Alone the problem are not 
> missing
> ideas/unknown needs but it is the still experimental state of LCB.
> 
> 
> 
> 
> ___
> 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: libsodium on LiveCode?

[Charles Warwick via use-livecode]

What type of key do you need to generate?

> On 21 Feb 2018, at 2:50 pm, Brian Milby via use-livecode 
>  wrote:
> 
> Had not seen the tsNet handler, but that is an RSA key. Scuttlebutt uses a
> different key type. There are other useful things in the library. There is
> some overlap, but enough different to make it worthy of an effort.
> 
> I’ll need to take a look at the MS links.
> 
> Hopefully the rest of today and tomorrow will go better!
> On Tue, Feb 20, 2018 at 10:13 PM Monte Goulding via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> 
>> 
>>> On 21 Feb 2018, at 2:57 pm, Brian Milby  wrote:
>>> 
>>> Monte, you are awesome!
>> 
>> Cheers! Not feeling so awesome today… been banging my head on something
>> all day and getting nowhere :-(
>>> 
>>> With your help I was able to generate a key pair using libSodium. That
>> means that we are one huge step closer to asymmetric key generation and use
>> within LC.
>> 
>> Hmm… have you seen tsNetGenerateKey ?
>>> 
>>> For each tool chain they provided a static and dynamic directory. The
>> static just contained a .lib file. The dynamic contains 3 or 4 files.
>> Starting at 140 a .pdb file is added. The latest one that works is v120.
>>> 
>>> Thanks for the help!
>> 
>> OK, I’m not sure why they aren’t working. The main thing I’d look for is
>> if they are built to dynamic link to the CRT and you don’t have the
>> corresponding version of MSVS or the redistributable packages installed.
>> You could try installing this and then test 140
>> https://www.microsoft.com/en-au/download/details.aspx?id=48145 <
>> https://www.microsoft.com/en-au/download/details.aspx?id=48145>
>> 
>> Cheers
>> 
>> Monte
>> 
>> ___
>> 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: LiveCode Widget Factory

[hh via use-livecode]

> Todd F. wrote:
> I have been in touch with a few people to get their ideas and needs,
> but I wanted to reach out and check with the community.
> At first, wehave decided to focus these for round one:
> Basic Native UI elements, Native Maps  

Please start with *cross-platform-native* widgets for all of the UI elements in
the LC Tools (which all are "basic").

Alone reaching that single target before 2021 would be a little wonder.

I admire what is possible already now with LCB. Alone the problem are not 
missing
ideas/unknown needs but it is the still experimental state of LCB.




___
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: LiveCode Widget Factory

[Roger Eller via use-livecode]

This sounds fantastic!!!  I have to ask, when you say "Native", do you mean
it should work on ANY of the "LiveCode-supported" platforms, both desktop
and/or mobile?

~Roger


On Wed, Feb 21, 2018 at 4:10 PM, Todd Fabacher via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hello LiveCoders,
>
> I hope all is going well. As Kevin announced before...Gurgen, myself, the
> DP team and the FANTASTIC  LiveCode team [providing wonderful support] are
> working on creating LCB widgets that will catapult the LC platform and
> improve productivity.
>
> I have been in touch with a few people to get their ideas and needs, but I
> wanted to reach out and check with the community. At first, we have decided
> to focus these for round one:
>
> Basic Native UI elements
> Native Maps
> Voice to Text
> Bluetooth Device Connection
> Beacons
> Security/Fingerprint
> Playing sound/music in the background when the phone sleeps like Spotify or
> iTunes.
>
> For Phase Two we are looking at...
> BarCode Scanner & Maker
> Charts
> iCal like Calendar [Day, Week, Month, Year]
> Clipboard for mobile
>
> We are mostly looking at creating many UI elements and functionality that
> is native and not accessible now and other widgets that will save days of
> coding by grouping functionality into one simple widget [with the difficult
> code encapsulated].
>
> A few of the controls will be open sourced but the vast majority will be
> for sale at a reasonable price. Sorry, Gurgen and Team don't work for free
> and my landlord does not have an open source building, so please save the
> digital trees with replies of why we should be open source.
>
> We are excited and will be working VERY hard. Good News, DP was VERY
> successful at the Seaside Summit in UEA. We also have two LiveCode based
> startups selected to be profiled at Collision Conference
> https://collisionconf.com in April. One App is coded for Android, iOS,
> Windows, MacOS, LINUX local Server & TV HDMI output and a big LiveCode
> Server implementation for the cloud. It uses TCP, UDP, HTTPS, and SFTP
> protocols. Extensive encryption and a distributed network that will have
> 200,000 simultaneous global users. WOW...all of this with one code base -
> that is the power of LiveCode.
>
> --DP & LC teams
> ___
> 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]

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

LiveCode Widget Factory

[Todd Fabacher via use-livecode]

Hello LiveCoders,

I hope all is going well. As Kevin announced before...Gurgen, myself, the
DP team and the FANTASTIC  LiveCode team [providing wonderful support] are
working on creating LCB widgets that will catapult the LC platform and
improve productivity.

I have been in touch with a few people to get their ideas and needs, but I
wanted to reach out and check with the community. At first, we have decided
to focus these for round one:

Basic Native UI elements
Native Maps
Voice to Text
Bluetooth Device Connection
Beacons
Security/Fingerprint
Playing sound/music in the background when the phone sleeps like Spotify or
iTunes.

For Phase Two we are looking at...
BarCode Scanner & Maker
Charts
iCal like Calendar [Day, Week, Month, Year]
Clipboard for mobile

We are mostly looking at creating many UI elements and functionality that
is native and not accessible now and other widgets that will save days of
coding by grouping functionality into one simple widget [with the difficult
code encapsulated].

A few of the controls will be open sourced but the vast majority will be
for sale at a reasonable price. Sorry, Gurgen and Team don't work for free
and my landlord does not have an open source building, so please save the
digital trees with replies of why we should be open source.

We are excited and will be working VERY hard. Good News, DP was VERY
successful at the Seaside Summit in UEA. We also have two LiveCode based
startups selected to be profiled at Collision Conference
https://collisionconf.com in April. One App is coded for Android, iOS,
Windows, MacOS, LINUX local Server & TV HDMI output and a big LiveCode
Server implementation for the cloud. It uses TCP, UDP, HTTPS, and SFTP
protocols. Extensive encryption and a distributed network that will have
200,000 simultaneous global users. WOW...all of this with one code base -
that is the power of LiveCode.

--DP & LC teams
___
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: Features and shortcomings of html5

[J. Landman Gay via use-livecode]

Thanks for the links, I'll keep them. The inability to use a mobile 
browser is a deal-breaker. That's exactly what I needed to know to 
decide the path forward, it's a significant limitation.


On 2/20/18 11:16 PM, hh via use-livecode wrote:

The laoding delay is very much dependent on how you configure your
server. If the server is optimized I have here with Safari < 9 secs
for the first load and < 3 secs for a reload, using the server of the
first link below.

The standalones mentioned are here [EU]
 http://hyperhh.org/html5/index-large.html
or here (same content) [US]
 http://hh.on-rev.com/html5/index-large.html

And here is an info: Forums/HTML5/Successful_test

Download right now what you need, because I'll remove soon all those
unneeded "basic experiments" (and, that's my method, trash them here
also).

p.s. You will have no luck running more than a primitive demo on mobile,
no matter the connection speed.



--
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

[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: libsodium on LiveCode?

[Bob Sneidar via use-livecode]

Sounds like my day yesterday. Hope you have a breakthrough today!

Bob S


> On Feb 20, 2018, at 20:12 , Monte Goulding via use-livecode 
>  wrote:
> 
>> Monte, you are awesome!
> 
> Cheers! Not feeling so awesome today… been banging my head on something all 
> day and getting nowhere :-(
> 

___
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