Developing first on android

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

Developing first on android

J. Landman Gay via use-livecode
I really appreciate something Jacqueline said in her presentation. If we start with Android deployment first, we can be pretty sure it will work on iOS.

How do you guys feel about this?

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

Re: Developing first on android

J. Landman Gay via use-livecode
There might be another way to skin this cat.  I liked what Pomegranate said,
which would also be a way to make apps even more levure/git-friendly, and
would, I think, solve some of the Android layout issues that she was
discussing - every object is created by a script, instead of using the LC
IDE to do it.  I've been thinking of developing a deconstructor to use with
Levure.  The idea is that you would lay out the objects, but then the
deconstructor would pull all the properties of each object, put them in a
YML, JSON, or other similar file, and then they would be built in the app
by  script, when needed.  That may give you additional flexibility when
doing Android or ios because you could build your own geometry manager for
mobile.
The other thing that I've been thinking about was doing the layouts in a
tool like Sketch (which would also mean that I could use some of the
interface design service companies like uichest and pixelbuddha more
easily).  That might also make the Android interface simpler to build and
manipulate, but I haven't played with the idea enough to really
understand it, yet.

On Thu, Aug 17, 2017 at 7:24 PM, Jonathan Lynch via use-livecode <
[hidden email]> wrote:

> I really appreciate something Jacqueline said in her presentation. If we
> start with Android deployment first, we can be pretty sure it will work on
> iOS.
>
> How do you guys feel about this?
>
> Sent from my iPhone
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Developing first on android

J. Landman Gay via use-livecode
I am not too worried about layout. I make extensive setlayout scripts to adjust to all screen sizes.

But it seems like Android is the pickiest platform for other reasons as well, so why not start there first? After I get Augmented Earth to work fully on Android, I think I am going to make future improvements starting on Android first.

I got a lot of good tips from her presentation - so thank you Jacqueline:)

Sent from my iPhone

> On Aug 17, 2017, at 9:31 PM, Mike Kerner via use-livecode <[hidden email]> wrote:
>
> There might be another way to skin this cat.  I liked what Pomegranate said,
> which would also be a way to make apps even more levure/git-friendly, and
> would, I think, solve some of the Android layout issues that she was
> discussing - every object is created by a script, instead of using the LC
> IDE to do it.  I've been thinking of developing a deconstructor to use with
> Levure.  The idea is that you would lay out the objects, but then the
> deconstructor would pull all the properties of each object, put them in a
> YML, JSON, or other similar file, and then they would be built in the app
> by  script, when needed.  That may give you additional flexibility when
> doing Android or ios because you could build your own geometry manager for
> mobile.
> The other thing that I've been thinking about was doing the layouts in a
> tool like Sketch (which would also mean that I could use some of the
> interface design service companies like uichest and pixelbuddha more
> easily).  That might also make the Android interface simpler to build and
> manipulate, but I haven't played with the idea enough to really
> understand it, yet.
>
> On Thu, Aug 17, 2017 at 7:24 PM, Jonathan Lynch via use-livecode <
> [hidden email]> wrote:
>
>> I really appreciate something Jacqueline said in her presentation. If we
>> start with Android deployment first, we can be pretty sure it will work on
>> iOS.
>>
>> How do you guys feel about this?
>>
>> Sent from my iPhone
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>   and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: Developing first on android

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
Mike Kerner wrote:

 > There might be another way to skin this cat.  I liked what Pomegranate
 > said, which would also be a way to make apps even more levure/git-
 > friendly, and would, I think, solve some of the Android layout issues
 > that she was discussing - every object is created by a script, instead
 > of using the LC IDE to do it.

Who is "Pomegranate" and where was this message? In a quick search of
recent posts here I was unable to turn up anything from that user.

Was Jonathan's issue specific to layout? I had thought it was a
reflection of a somewhat general sense that LC's feature set for Android
is in some ways a subset of features found in LC's iOS engine.  To the
degree that's true, Jacque's suggestion is a great one, since the range
of things we can do in Android that aren't available on LC's iOS engine
does seem smaller than the other way around.

If not limited to layout, how would the storage format of the objects
affect that?  Whether rebuilt on the fly each time from script or
instantiated from op codes in the binary stack file, an object is an object.

Even for layout, it seems the benefit of using Git-based workflows is
for the benefits of using Git, in development, and would not seem to
alter runtime behavior.  Have I missed some feature unique to
script-only stacks?


The only downside I can think of to using any single OS for the majority
of one's multi-platform development is to make sure you periodically run
in each of the target OSes to ensure things look as they should.

For example on mobile, a menu button row/widget appears at the top of
the layour in Android (not a bad choice, given that people tend to
perceive layouts in reading order, left to right and top to bottom), but
on iOS that main navigation control is placed below the region it
affects, at the bottom of the card.

There aren't many things like that which differ so starkly, unless you
get deeply into Android's Material Design.  But if we want to avoid
having our apps look like something that was obviously designed for some
other OS and hastily ported we want to learn those differences and
support them in our layout code.


 > I've been thinking of developing a deconstructor to use with Levure.
 >  The idea is that you would lay out the objects, but then the
 > deconstructor would pull all the properties of each object, put them
 > in a YML, JSON, or other similar file, and then they would be built in
 > the app by  script, when needed.

That would be handy.  I've considered making one, but the cost/benefit
relative to other commitments here has prevented me from diving in. I
appreciate your interest in this, and know you'll do a fine job with it.

While it's understandable that Git can't handle LC's binary files, one
of the strongest benefits of "The xTalk Way" is visual design.

This is why so many of us have written libraries to automatically
instantiate mobile-specific controls for us from LC-native objects,
because it lets us enjoy the fluid development workflow that
characterizes xTalks, rather than defining objects by typing long blocks
of object definitions in scripts, which is a very C way of doing things.

Automating use of Git through binary->script decomposers allows
developers the full benefit of the best of both xTalk and lower-level
workflows.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

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

Re: Developing first on android

J. Landman Gay via use-livecode
I blame Spell Checker.

Bob S


> On Aug 18, 2017, at 07:56 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> Who is "Pomegranate" and where was this message? In a quick search of recent posts here I was unable to turn up anything from that user.


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

Re: Developing first on android

J. Landman Gay via use-livecode
Sorry, I assumed everyone was at Global, yesterday.  During the keynote, an
interview with Digital Pomegranate was shown.  During that interview, there
was a lengthy explanation about building LC apps, and things that they do.

On Fri, Aug 18, 2017 at 11:04 AM, Bob Sneidar via use-livecode <
[hidden email]> wrote:

> I blame Spell Checker.
>
> Bob S
>
>
> > On Aug 18, 2017, at 07:56 , Richard Gaskin via use-livecode <
> [hidden email]> wrote:
> >
> > Who is "Pomegranate" and where was this message? In a quick search of
> recent posts here I was unable to turn up anything from that user.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Developing first on android

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
What about a non-binary stack file format?  Something XML based and derived
from the actual in-memory stack object (would need to be integrated with
the IDE/engine to be really useful though - to allow seamless/native
import/export).


> Mike Kerner wrote:
>
> > I've been thinking of developing a deconstructor to use with Levure.
> >  The idea is that you would lay out the objects, but then the
> > deconstructor would pull all the properties of each object, put them
> > in a YML, JSON, or other similar file, and then they would be built in
> > the app by  script, when needed.
>
> That would be handy.  I've considered making one, but the cost/benefit
> relative to other commitments here has prevented me from diving in. I
> appreciate your interest in this, and know you'll do a fine job with it.
>
> While it's understandable that Git can't handle LC's binary files, one of
> the strongest benefits of "The xTalk Way" is visual design.
>
> This is why so many of us have written libraries to automatically
> instantiate mobile-specific controls for us from LC-native objects, because
> it lets us enjoy the fluid development workflow that characterizes xTalks,
> rather than defining objects by typing long blocks of object definitions in
> scripts, which is a very C way of doing things.
>
> Automating use of Git through binary->script decomposers allows developers
> the full benefit of the best of both xTalk and lower-level workflows.
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Developing first on android

J. Landman Gay via use-livecode
On 2017-08-18 18:05, Brian Milby via use-livecode wrote:
> What about a non-binary stack file format?  Something XML based and
> derived
> from the actual in-memory stack object (would need to be integrated
> with
> the IDE/engine to be really useful though - to allow seamless/native
> import/export).

I think Monte's lcVCS might well be a good starting point for that -
there's no real need to have engine support as long as we make sure all
the things you need to know to deconstruct / reconstruct a stackfile are
accessible from script (which is where the engine support kicks in).

That being said, there is one piece of engine functionality which would
make lcVCS and similar tools much simpler - the ability to ask the
engine for a LiveCode array representing the actual persistent state of
any LiveCode object. If you have an array which contains a faithful
representation of the persistent state, then you can write serializers /
deserializers to whatever text (or other!) format you like in LiveCode
Script (which is a much much better place for such things to be!).

There is a starting point here for this. In order to allow lcVCS to
support widgets (which can have arbitrary persistent state), we added a
new form to the 'export' and 'import' commands:

export <widget> to array <arrayVar>
import <widget> from array <arrayVar>

We also added 'is strictly' operators which allow you to detect the
actual dynamic type of a value, rather than what values it could be:

   put "100" is a number -- true
   put "100" is strictly a number -- false

This allows lcVCS to create a faithful representation (in JSON) of the
values in LiveCode variables - in particular, in those returned from
export/import widget.

The reason I mention this is that this ability really is the precursor
to eliminating the engine's dependence on a bespoke binary stackfile
format (which is actually a huge problem - for all kinds of reasons) -
if we had a fully faithful (in the strict mathematical sense!)
import/export array ability - a stackfile could just become an array
which has been encoded with any hierarchical data encoding format (of
which the arrayEncode format is one, JSON is another, BSON is another,
YAML is another, ...).

It might be that the part of lcVCS which does the JSON mapping might
well be completely sufficient - perhaps Monte could chime in here to
comment and remind me of the issues he had / faced with it.

I can recall one significant issue - the properties we set on objects
(or widgets - lamentably) are not necessarily reflective of the
persistent state. What I mean by this is that, in some case, you cannot
directly set one of the internal persistent state variables of an object
directly by a property - it can only be done by setting a combination,
or by other actions (I'd need to look through the engine code to remind
myself where this occurs).

However *that* is fixable - we make sure that there are suitably human
understandable properties for all objects which ensure you can easily
import and export them using just those properties. For widgets, it
comes to down to imposing a simple rule:

Any piece of state which is saved into the state array (on OnSave)
*must* be accessible by a public property.

This would actually simplify widget creation - as you wouldn't need an
OnLoad / OnSave handler at all then. It would just be a case of
serializing the properties which are marked as 'persistent'. This is one
case where I modelled the engine's behavior, and shouldn't have done - I
should have ignored how the engine did things and just gone with 'what
made more sense'!

Anyway, I'd suggest we start looking at lcVCS (in terms of its object
import/export - not the VC related aspects) and see what issues it has;
then look at starting to fix those issues in the engine; then look to
start adding array import/export methods for all LiveCode objects...
Assuming this is an interesting project someone (not looking at anyone
in particular ;)) would like to take up...

Warmest Regards,

Mark.

>> Mike Kerner wrote:
>>
>> > I've been thinking of developing a deconstructor to use with Levure.
>> >  The idea is that you would lay out the objects, but then the
>> > deconstructor would pull all the properties of each object, put them
>> > in a YML, JSON, or other similar file, and then they would be built in
>> > the app by  script, when needed.
>>
>> That would be handy.  I've considered making one, but the cost/benefit
>> relative to other commitments here has prevented me from diving in. I
>> appreciate your interest in this, and know you'll do a fine job with
>> it.
>>
>> While it's understandable that Git can't handle LC's binary files, one
>> of
>> the strongest benefits of "The xTalk Way" is visual design.
>>
>> This is why so many of us have written libraries to automatically
>> instantiate mobile-specific controls for us from LC-native objects,
>> because
>> it lets us enjoy the fluid development workflow that characterizes
>> xTalks,
>> rather than defining objects by typing long blocks of object
>> definitions in
>> scripts, which is a very C way of doing things.
>>
>> Automating use of Git through binary->script decomposers allows
>> developers
>> the full benefit of the best of both xTalk and lower-level workflows.
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: Developing first on android

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
On 8/17/17 8:31 PM, Mike Kerner via use-livecode wrote:
> I liked what Pomegranate said,
> which would also be a way to make apps even more levure/git-friendly, and
> would, I think, solve some of the Android layout issues that she was
> discussing - every object is created by a script, instead of using the LC
> IDE to do it.

This method also works well, and I've used it in a couple of projects.
But being basically lazy, I like to follow the rule to "let the engine
do it" whenever possible. If you aren't using git or your layouts aren't
dynamic, it's much easier to let the engine do the resizing and scaling
for you, and the tricks I mentioned are an easy way to overcome a few
limitations.

One other comment about my presentation: the problem with issuing the
"quit" command was just fixed and is now awaiting merge. :) Now all we
need is suspend/resume messages and the main Android issues will go away.

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

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

Re: Developing first on android

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
If I'm understanding correctly, a capability to export a stack as an array
(with the corresponding import) would get around the issue of the
non-public properties though.  The array would be the intermediate format
that would be used by the engine to construct the stack in memory.  LCS
could be used to serialize into a suitable disk format.  It would mean that
the only way to get a full representation of the object would be to use the
full import if there were properties like you described above (unless I'm
missing something).

I've actually been mulling something along these lines over for the past
few weeks (but was thinking about a direct XML format).  I briefly looked
at the code to save a stack and noticed how it seems pretty straight
forward.  I'll take a look at the code for some of the objects this weekend
and see what I think.  Could be a good opportunity for the community to
contribute a useful new feature.

On Fri, Aug 18, 2017 at 11:56 AM, Mark Waddingham via use-livecode <
[hidden email]> wrote:

> On 2017-08-18 18:05, Brian Milby via use-livecode wrote:
>
>> What about a non-binary stack file format?  Something XML based and
>> derived
>> from the actual in-memory stack object (would need to be integrated with
>> the IDE/engine to be really useful though - to allow seamless/native
>> import/export).
>>
>
> I think Monte's lcVCS might well be a good starting point for that -
> there's no real need to have engine support as long as we make sure all the
> things you need to know to deconstruct / reconstruct a stackfile are
> accessible from script (which is where the engine support kicks in).
>
> That being said, there is one piece of engine functionality which would
> make lcVCS and similar tools much simpler - the ability to ask the engine
> for a LiveCode array representing the actual persistent state of any
> LiveCode object. If you have an array which contains a faithful
> representation of the persistent state, then you can write serializers /
> deserializers to whatever text (or other!) format you like in LiveCode
> Script (which is a much much better place for such things to be!).
>
> There is a starting point here for this. In order to allow lcVCS to
> support widgets (which can have arbitrary persistent state), we added a new
> form to the 'export' and 'import' commands:
>
> export <widget> to array <arrayVar>
> import <widget> from array <arrayVar>
>
> We also added 'is strictly' operators which allow you to detect the actual
> dynamic type of a value, rather than what values it could be:
>
>   put "100" is a number -- true
>   put "100" is strictly a number -- false
>
> This allows lcVCS to create a faithful representation (in JSON) of the
> values in LiveCode variables - in particular, in those returned from
> export/import widget.
>
> The reason I mention this is that this ability really is the precursor to
> eliminating the engine's dependence on a bespoke binary stackfile format
> (which is actually a huge problem - for all kinds of reasons) - if we had a
> fully faithful (in the strict mathematical sense!) import/export array
> ability - a stackfile could just become an array which has been encoded
> with any hierarchical data encoding format (of which the arrayEncode format
> is one, JSON is another, BSON is another, YAML is another, ...).
>
> It might be that the part of lcVCS which does the JSON mapping might well
> be completely sufficient - perhaps Monte could chime in here to comment and
> remind me of the issues he had / faced with it.
>
> I can recall one significant issue - the properties we set on objects (or
> widgets - lamentably) are not necessarily reflective of the persistent
> state. What I mean by this is that, in some case, you cannot directly set
> one of the internal persistent state variables of an object directly by a
> property - it can only be done by setting a combination, or by other
> actions (I'd need to look through the engine code to remind myself where
> this occurs).
>
> However *that* is fixable - we make sure that there are suitably human
> understandable properties for all objects which ensure you can easily
> import and export them using just those properties. For widgets, it comes
> to down to imposing a simple rule:
>
> Any piece of state which is saved into the state array (on OnSave) *must*
> be accessible by a public property.
>
> This would actually simplify widget creation - as you wouldn't need an
> OnLoad / OnSave handler at all then. It would just be a case of serializing
> the properties which are marked as 'persistent'. This is one case where I
> modelled the engine's behavior, and shouldn't have done - I should have
> ignored how the engine did things and just gone with 'what made more sense'!
>
> Anyway, I'd suggest we start looking at lcVCS (in terms of its object
> import/export - not the VC related aspects) and see what issues it has;
> then look at starting to fix those issues in the engine; then look to start
> adding array import/export methods for all LiveCode objects... Assuming
> this is an interesting project someone (not looking at anyone in particular
> ;)) would like to take up...
>
> Warmest Regards,
>
> Mark.
>
> Mike Kerner wrote:
>>>
>>> > I've been thinking of developing a deconstructor to use with Levure.
>>> >  The idea is that you would lay out the objects, but then the
>>> > deconstructor would pull all the properties of each object, put them
>>> > in a YML, JSON, or other similar file, and then they would be built in
>>> > the app by  script, when needed.
>>>
>>> That would be handy.  I've considered making one, but the cost/benefit
>>> relative to other commitments here has prevented me from diving in. I
>>> appreciate your interest in this, and know you'll do a fine job with it.
>>>
>>> While it's understandable that Git can't handle LC's binary files, one of
>>> the strongest benefits of "The xTalk Way" is visual design.
>>>
>>> This is why so many of us have written libraries to automatically
>>> instantiate mobile-specific controls for us from LC-native objects,
>>> because
>>> it lets us enjoy the fluid development workflow that characterizes
>>> xTalks,
>>> rather than defining objects by typing long blocks of object definitions
>>> in
>>> scripts, which is a very C way of doing things.
>>>
>>> Automating use of Git through binary->script decomposers allows
>>> developers
>>> the full benefit of the best of both xTalk and lower-level workflows.
>>>
>>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
> --
> Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Developing first on android

J. Landman Gay via use-livecode
I'll weigh in here. An array representation of a stack might be useful in ways, such as storing it as a property of another stack, or writing it as a binary file to disk as a backup of sorts after arrayEncoding it.

Just so long as no one thinks they can do something like take the key that represents say a button and copy it to another stack array, or a different place in the first array, all will be well. All kinds of nasties happen with ID's and linked graphics and whatnot just copying a button with a linked graphic to another card.

Bob S


> On Aug 18, 2017, at 15:12 , Brian Milby via use-livecode <[hidden email]> wrote:
>
> If I'm understanding correctly, a capability to export a stack as an array
> (with the corresponding import) would get around the issue of the
> non-public properties though.  The array would be the intermediate format
> that would be used by the engine to construct the stack in memory.  LCS
> could be used to serialize into a suitable disk format.  It would mean that
> the only way to get a full representation of the object would be to use the
> full import if there were properties like you described above (unless I'm
> missing something).
>
> I've actually been mulling something along these lines over for the past
> few weeks (but was thinking about a direct XML format).  I briefly looked
> at the code to save a stack and noticed how it seems pretty straight
> forward.  I'll take a look at the code for some of the objects this weekend
> and see what I think.  Could be a good opportunity for the community to
> contribute a useful new feature.


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

Re: Developing first on android

J. Landman Gay via use-livecode
I can see that.  If using the export as a way to track where you made
changes, it would be good to have it in a text format.  I've not gotten far
enough into the object code to tell when/where it would be safe to edit
such an array.  This will need to be something considered when writing the
import code.

On Fri, Aug 18, 2017 at 5:48 PM, Bob Sneidar via use-livecode <
[hidden email]> wrote:

> I'll weigh in here. An array representation of a stack might be useful in
> ways, such as storing it as a property of another stack, or writing it as a
> binary file to disk as a backup of sorts after arrayEncoding it.
>
> Just so long as no one thinks they can do something like take the key that
> represents say a button and copy it to another stack array, or a different
> place in the first array, all will be well. All kinds of nasties happen
> with ID's and linked graphics and whatnot just copying a button with a
> linked graphic to another card.
>
> Bob S
>
>
> > On Aug 18, 2017, at 15:12 , Brian Milby via use-livecode <
> [hidden email]> wrote:
> >
> > If I'm understanding correctly, a capability to export a stack as an
> array
> > (with the corresponding import) would get around the issue of the
> > non-public properties though.  The array would be the intermediate format
> > that would be used by the engine to construct the stack in memory.  LCS
> > could be used to serialize into a suitable disk format.  It would mean
> that
> > the only way to get a full representation of the object would be to use
> the
> > full import if there were properties like you described above (unless I'm
> > missing something).
> >
> > I've actually been mulling something along these lines over for the past
> > few weeks (but was thinking about a direct XML format).  I briefly looked
> > at the code to save a stack and noticed how it seems pretty straight
> > forward.  I'll take a look at the code for some of the objects this
> weekend
> > and see what I think.  Could be a good opportunity for the community to
> > contribute a useful new feature.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Developing first on android

J. Landman Gay via use-livecode
Hi Folks

lcVCS was invented before script only stacks and for the most part script only stacks covers the use case much better. If you have a complicated stackFile then no matter what text representation we make of it you would get lost dealing with merge conflicts and diffs. If you don’t believe me try looking at an Xcode storyboard merge conflict… it’s no fun. You really are better off just being careful to avoid working on ui stuff on multiple branches. If you have a trivial UI then you can generate it on the fly as we do with some stacks in the IDE. If you have something a little bit too complicated for hand coding generation on the fly then you could use something like the scriptonlyUI library I experimented with one rainy day https://github.com/montegoulding/scriptonlyui <https://github.com/montegoulding/scriptonlyui>. Anything more complicated is just as well off staying a binary file and using script only behaviors for scripts.

Having said that there _are_ a couple of stack properties that we could add to script only stacks to make things work better and I don’t think it would be all that tricky to add something YAML like that the engine reads between the `script “<StackName>”` header and the stack script.

The properties that I would add are behavior and stackFiles so your script only stack would look like this:

script “StackName”
---
behavior: stack “ParentBehavior”
stackFiles:
- ParentBehavior: some/path.livecodescript
---
command MyHandler
  -- code
end MyHandler

There could be some other properties that would be helpful but I think these are the critical ones causing issues for behavior hierarchies which are lost when saving so you need to script them. Perhaps even stackFiles isn’t that necessary as the stackFiles could be set on a binary stack elsewhere or the stack could be in a location the engine would find it.

We would probably only want to add properties that we feel are causing issues which behavior definitely is. The less you add the less chance of a merge conflict on some change you didn’t intent. Of course once you add _any_ properties it’s suddenly _not_ a script only stack so…

BTW if we only wanted to add behavior and only stack behaviors at that it might be nice to just include that in the header:

script “StackName” with behavior “ParentBehavior”
command MyHandler
  — code
end MyHandler

I actually really like this option as it’s in keeping with the original faceless script object concept.

Cheers

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

Re: Developing first on android

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
 
 

 What about handlers?    Stacks already call preOpenStack and related handlers.    Adding handlers that get called automatically would leave it as script only but allow for post-load initialization.    I haven't looked to see what is already processed though.
 

 
 

 
 
>  
> On Aug 19, 2017 at 10:58 PM,  <Monte Goulding via use-livecode (mailto:[hidden email])>  wrote:
>  
>  
>  
>  Hi Folks lcVCS was invented before script only stacks and for the most part script only stacks covers the use case much better. If you have a complicated stackFile then no matter what text representation we make of it you would get lost dealing with merge conflicts and diffs. If you don’t believe me try looking at an Xcode storyboard merge conflict… it’s no fun. You really are better off just being careful to avoid working on ui stuff on multiple branches. If you have a trivial UI then you can generate it on the fly as we do with some stacks in the IDE. If you have something a little bit too complicated for hand coding generation on the fly then you could use something like the scriptonlyUI library I experimented with one rainy day https://github.com/montegoulding/scriptonlyui . Anything more complicated is just as well off staying a binary file and using script only behaviors for scripts. Having said that there _are_ a couple of stack properties that we could add to script only stacks to make things work better and I don’t think it would be all that tricky to add something YAML like that the engine reads between the `script “”` header and the stack script. The properties that I would add are behavior and stackFiles so your script only stack would look like this: script “StackName” --- behavior: stack “ParentBehavior” stackFiles: - ParentBehavior: some/path.livecodescript --- command MyHandler -- code end MyHandler There could be some other properties that would be helpful but I think these are the critical ones causing issues for behavior hierarchies which are lost when saving so you need to script them. Perhaps even stackFiles isn’t that necessary as the stackFiles could be set on a binary stack elsewhere or the stack could be in a location the engine would find it. We would probably only want to add properties that we feel are causing issues which behavior definitely is. The less you add the less chance of a merge conflict on some change you didn’t intent. Of course once you add _any_ properties it’s suddenly _not_ a script only stack so… BTW if we only wanted to add behavior and only stack behaviors at that it might be nice to just include that in the header: script “StackName” with behavior “ParentBehavior” command MyHandler — code end MyHandler I actually really like this option as it’s in keeping with the original faceless script object concept. Cheers Monte _______________________________________________ use-livecode mailing list [hidden email] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode 
>
>  
 
 
 
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Developing first on android

J. Landman Gay via use-livecode

> On 21 Aug 2017, at 5:48 am, Brian Milby via use-livecode <[hidden email]> wrote:
>
> What about handlers?    Stacks already call preOpenStack and related handlers.    Adding handlers that get called automatically would leave it as script only but allow for post-load initialization.    I haven't looked to see what is already processed though.

Hmm… I’m not sure what you mean here. Script only stacks are sent the same messages as binary stacks. Do you think they need something else? I have suggested a `loadStack` message here for when a stack is loaded into memory but that’s not specific to script only stacks either. http://quality.livecode.com/show_bug.cgi?id=18223 <http://quality.livecode.com/show_bug.cgi?id=18223>

Cheers

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

Re: Developing first on android

J. Landman Gay via use-livecode
In reply to this post by J. Landman Gay via use-livecode
 
 

 Ok, in that case, would the following work:
 

 
On openStack
 
      Set the behavior of me to stack "parent"
 
      Set the behavior of stack "child" to me
 
End openStack
 

 
There may be some need to check that referenced stacks are open, but just did some experimenting to verify that the calls work in the IDE.    I'm guessing you would want to possibly have them only set in one direction though.
 

 
Thanks,
 
Brian
 
 

 
>  
> On Aug 20, 2017 at 3:51 PM,  <Monte Goulding via use-livecode (mailto:[hidden email])>  wrote:
>  
>  
>  
>   >  On 21 Aug 2017, at 5:48 am, Brian Milby via use-livecode wrote:  >   >  What about handlers? Stacks already call preOpenStack and related handlers. Adding handlers that get called automatically would leave it as script only but allow for post-load initialization. I haven't looked to see what is already processed though. Hmm… I’m not sure what you mean here. Script only stacks are sent the same messages as binary stacks. Do you think they need something else? I have suggested a `loadStack` message here for when a stack is loaded into memory but that’s not specific to script only stacks either. http://quality.livecode.com/show_bug.cgi?id=18223 Cheers Monte _______________________________________________ use-livecode mailing list [hidden email] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode 
>
>  
 
 
 
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Developing first on android

J. Landman Gay via use-livecode

> On 21 Aug 2017, at 9:22 am, Brian Milby via use-livecode <[hidden email]> wrote:
>
>
> Ok, in that case, would the following work:
>
>
>
> On openStack
>
>      Set the behavior of me to stack "parent"
>
>      Set the behavior of stack "child" to me
>
> End openStack
>
>
>
> There may be some need to check that referenced stacks are open, but just did some experimenting to verify that the calls work in the IDE.    I'm guessing you would want to possibly have them only set in one direction though.

That is what we do now although as a behavior can be used but not opened you would need to do that in the stack that uses the behavior. So you have stack A. The stack that uses the behavior which is a binary stackFile. Stack B the script only behavior of stack A. Stack C the script only behavior of stack B.

Right now you need to handle preOpenStack in stack A and setup the hierarchy because stack B does not retain the behavior property when saved and does not get any kind of message when used as a behavior. It may actually be a good idea to add a loadBehavior and unloadBehavior message sent to the object using the behavior so it can initialise its own heirarchy. Still I think saving the behavior property with the script only stack is a simpler solution.

Cheers

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

Array literals and script only stack initialization (was Re: Developing first on android)

J. Landman Gay via use-livecode
On 2017-08-21 01:31, Monte Goulding via use-livecode wrote:
> Right now you need to handle preOpenStack in stack A and setup the
> hierarchy because stack B does not retain the behavior property when
> saved and does not get any kind of message when used as a behavior. It
> may actually be a good idea to add a loadBehavior and unloadBehavior
> message sent to the object using the behavior so it can initialise its
> own heirarchy. Still I think saving the behavior property with the
> script only stack is a simpler solution.

I think its been suggested before that a 'loadStack' message might be
quite useful (perhaps it should be 'createStack' - we have 'deleteStack'
which is probably sufficient for the antonym) - allowing a stack to 'do
something' when it is loaded into memory, and then unloaded (equivalent
to OnCreate / OnDestroy in LCB) as loading/unloading is a slightly
different part of the life-cycle compared to opening and closing.

I can certainly see that it would be a 'simpler' solution in some ways
to save the behavior property - however, then it isn't 'just' a script
anymore - it is actually just a cut down object, so that leads us into
having general properties / structures encoded in a 'script only stack'.

I was playing about with prototyping something yesterday - array
literals - it has been suggested before (indeed I thought there was a
partial attempt by someone before - but I couldn't find it) but I
thought it would be interesting to try it:
https://github.com/livecode/livecode/pull/5824

Basically this patch adds JSON-like (which is LCB-like too!) syntax for
sequence (numerically keyed array) and array (associative array)
literals:

   put [ 1, 2, [ 3, 4, { "size" : the length of tOtherSeq } ] ] into
tSeqVar
   put { "foo" : "bar", "baz" : tMyValue , tMyKey : [ 1, 2, 3 ] } into
tArrVar

The syntax is the same as in LCB - keys and values can be static or
constant. The implementation has the nice property (well, the sequence
version does - the array one isn't quite finished yet) that actual
constant literals (those which have constant key/values which can be
evaluated at compile time) will share the value. i.e.

   put [ 1, 2, 3 ] into tSeqVar1
   put [ 1, 2, 3 ] into tSeqVar2 -- this will actually share the
in-memory value with tSeqVar1

This means that you can explicitly write the same constant anywhere, as
much as you like in script and still only have one instance of it.
Indeed, the performance of using array literals compared to separate
'put' statements to construct them is quite encouraging:

    BenchmarkStartTiming "LegacyCreation"
    repeat kRepetitions times
       get empty
       put true into tLegacyLiteral[1]
       put 1 into tLegacyLiteral[2]
       put pi into tLegacyLiteral[3]
       put "Hello" into tLegacyLiteral[4]
       put false into tLegacyLiteral[5]
       put 2 into tLegacyLiteral[6]
       put pi into tLegacyLiteral[7]
       put "World!" into tLegacyLiteral[8]
       put it into tLegacyLiteral[9]
    end repeat
    BenchmarkStopTiming

    BenchmarkStartTiming "ConstantCreation"
    repeat kRepetitions times
       get [ true, 1, pi, "Hello", false, 2, pi, "World!", [ true, 1, pi,
"Hello", false, 2, pi, "World!" ] ]
    end repeat
    BenchmarkStopTiming

    BenchmarkStartTiming "LegacyDynamicCreation"
    repeat kRepetitions times
       put empty into tLegacyLiteral
       put _Identity(true) into tLegacyLiteral[tOne]
       put _Identity(1) into tLegacyLiteral[tTwo]
       put _Identity(pi) into tLegacyLiteral[tThree]
       put _Identity("Hello") into tLegacyLiteral[tFour]
    end repeat
    BenchmarkStopTiming

    BenchmarkStartTiming "DynamicCreation"
    repeat kRepetitions times
       get [ _Identity(true), _Identity(1), _Identity(pi),
_Identity("Hello") ]
    end repeat
    BenchmarkStopTiming

Note: In the 'LegacyDynamicCreation' test variables holding actual
numbers and not numeric literals are used as that is a fairer test with
how things work at present (a technical detail - literals such as 1 are
actually stored internally ready for being used as an array key; whereas
dynamic creation has to create a key from the actual index 1).

On my machine I get the following results:

        LegacyConstantCreation 3037 ms
        ConstantCreation 53 ms
        LegacyDynamicCreation 10330 ms
        DynamicCreation 6496 ms

So there's certainly a significant performance advantage.

My only concern is introducing more symbols. There is another option
here using ( ) can also be made unambiguous:

   ( expr ) - grouped expr

   ( expr , ) - single element sequence

   ( expr : expr ) - single key/value

However, I wonder if this is a bit too subtle - it would be all too easy
to use ( expr ) for when you actually want a single element list - no
amount of context can really help here.

This also overlaps with recent discussions about strings. The syntax of
literals above is the same as JSON (and can be made compatible with
Python, just by allowing a trailing ',' in lists) *except* that LCS
strings are not escaped so they aren't necessary copy/paste comparison.
Therefore it does suggest that making "..." escaped strings as
cross-compatible with other languages as possible is maybe something to
seriously consider (if we wanted Python cross-compatibility '...' type
strings would have to be too - although Python has about 6 variants of
strings, you can use letter prefixes before the quote to change the
interpretation of the string).

Anyway, getting back to the original point of the original post... The
reason this might be of interest to the problem of script only stacks is
that with a suitable 'loadStack' type method, you could do something
like:

on loadStack
   set the properties of me to { \
     ... key/value pairs of properties ... \
   }
end loadStack

Indeed, if we had a better 'properties' property (i.e. as suggested by
me in terms of import/export array - something allowing you to get/set
the core persistent state of an object directly) then you could have
script-only-stacks which *also* contain their state (and, by collorary,
state of objects on the stack) - via having code which does it.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: Array literals and script only stack initialization (was Re: Developing first on android)

J. Landman Gay via use-livecode

> On 21 Aug 2017, at 7:58 pm, Mark Waddingham via use-livecode <[hidden email]> wrote:
>
> I think its been suggested before that a 'loadStack' message might be quite useful (perhaps it should be 'createStack' - we have 'deleteStack' which is probably sufficient for the antonym) - allowing a stack to 'do something' when it is loaded into memory, and then unloaded (equivalent to OnCreate / OnDestroy in LCB) as loading/unloading is a slightly different part of the life-cycle compared to opening and closing.

@LCMark I feel bad snipping discussion of the array literals because… AWESOME!!!  but I actually only wanted to comment on `createStack` feelign a bit wrong if we also have `newStack` and the `create stack` command would send `newStack` not `createStack`.. or maybe it would send both but you can see why I have an issue with it ;-)

Cheers

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

Re: Array literals and script only stack initialization (was Re: Developing first on android)

J. Landman Gay via use-livecode
On 2017-08-21 12:06, Monte Goulding via use-livecode wrote:

>> On 21 Aug 2017, at 7:58 pm, Mark Waddingham via use-livecode
>> <[hidden email]> wrote:
>>
>> I think its been suggested before that a 'loadStack' message might be
>> quite useful (perhaps it should be 'createStack' - we have
>> 'deleteStack' which is probably sufficient for the antonym) - allowing
>> a stack to 'do something' when it is loaded into memory, and then
>> unloaded (equivalent to OnCreate / OnDestroy in LCB) as
>> loading/unloading is a slightly different part of the life-cycle
>> compared to opening and closing.
>
> @LCMark I feel bad snipping discussion of the array literals because…
> AWESOME!!!  but I actually only wanted to comment on `createStack`
> feelign a bit wrong if we also have `newStack` and the `create stack`
> command would send `newStack` not `createStack`.. or maybe it would
> send both but you can see why I have an issue with it ;-)

Heh! That post was perhaps a bit 'thick' on content. The literals stuff
probably should have got its own thread - they are pretty cool, the
extra symbols needed are irksome but (just like with strings) I think
resigning ourselves to the fact that different bracket types (in
particular) are the best way to represent (in text) hierarchical data is
just something we will have to do.

Back to the point of your post... I see what you mean about 'newStack' /
'deleteStack' - I had a similar thought whilst writing the email. Too
many messages and it will just get confusing, too few and its not
flexible enough. However, it might be we do need a new pair of messages
here, and clarify precisely what the existing and new ones are for.

Of course, we also have the 'lock messages' issue - something which
increasingly makes me wonder whether the message path is being
'overloaded' in use. It works very very well for events which you might
want to 'bubble'; but I'm becoming increasingly convinced that is not
quite right for (1) things which are related to a specific object (e.g.
life-cycle messages); (2) libraries. [ There's a whole corollary here
with being able to call methods 'inside' widgets here too - the 'do ...
in widget' problem; it is a similar if not quite the same ].

Anyway, the latter is a somewhat large thought-project in and of itself.
Certainly there are aspects of LCB which I think work better where the
message path is very much a separate thing which widgets use (but aren't
strictly a part of); but on the other hand there are issues still with
integrating widgets into the message path (mouse messages and such).

So, in the short term, if there is an extra message-path message which
*would* help make script-only-stacks more flexible, then we should
perhaps seriously consider it - if we can make it tasteful enough!

Of course, another approach here is to keep script only stacks as they
are (the header uses 'script' for a reason) - and then have a different
form for objects which is a text serialization of *core* properties and
script:

   stack "MyStack"

   set property behavior is ...

   set property title is ...

   on openStack
   end openStack

Or something (I just came up with that off the top of my head - so needs
'reading between the lines' of the intent). With array properties,
hierarchical properties could also be set.

As with any text-based representation of stackfiles, custom properties
cause a significant problem here which is why I suggest that only core
persistent properties should be allowed. So, even with this kind of form
you'd still need a way to init them, which takes us back to the adding a
message which allows such init - and then the need for 'stack ...' type
script only stacks reduces - it is entirely equivalent to just having
code in that init message which uses literals to init properties.
Anything like the above just becomes 'syntactic sugar'.

In terms of language design, we need to be careful to ensure that
anything you can do with 'syntactic sugar' does have a code-based
equivalent - the latter coming first. The reason here is that it means
that there is no engine 'magic', it can all be done in script; and the
more engine 'magic' which is de-magicised, the more script can do.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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