Converting scripts in stacks to script only stack behaviors

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

Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
I created a screencast showing how you can convert the scripts in your
stacks to script only behavior stacks using a new Property Inspector
feature in LiveCode 9 (still in early development). Storing your code in
script only stacks allows you to manage your application with source
control software such as git.

https://www.youtube.com/watch?v=eyggLzIbeSU

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

Re: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
Thank you Trevor - a really nice video!

I’ve been using script-only stacks for a while for code libraries, never realised how easy it was to use them to effectively make ‘script-only behaviors’ :)

Kind regards

Dave


_______________________________________________
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: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
Trevor, thanks for that intro to the new tools in LC9


I'm already using libraries and behaviors extensively, but still find my self build LC stack binaries with a full stack script or, quite often,  95% of the code in the card script (if the UI can all be done on a single card)

The other day I was thinking 'gee, why not just move this card script out to a behavior and assign it to the card."  been mulling this over for a few days, the the work flow for making this transition seemed onerous, but LC9 will make it soooo easy!

Our new app, SivaSiva, is being done with GIT and this is the first time working with GIT for something like this… for web and RevIgniter, GIT make obvious sense, since the whole environment is text files from the ground up.

But now, with the new app, we have this mix of text only scripts and binary *.livecode stacks.

So this leads to two more interesting avenue of adventure/explorations

1) we are already hitting GIT conflicts with the main stack of the project because if one developer needs to add some stack files, or wants to change a standalone setting for testing a build on a device, the IDE of course requires a Save… so now this stack must be either stashed (assuming you don’t need the changes) or committed.. and we hit a conflict later that is not so easily resolved.

2) building UI from script: every now and the notion passes by that perhaps building UI from script has advantages of  the LC WSIWIG model. I was  intrigued in your to see in the background in sublime text, you had a handler that built some of the UI.  perhaps all of it for that dialog box?  
So the question then becomes when, where and why do we make a decision to go the route to build UI by script? I guess the one obvious answer is that you want to put the UI under git control so that we have, as you put it "fine-grained control over changes, edits, history" etc.

I wonder if there are other criteria besides that. Possibly building UI be script may be better suited to responsive design, since, in the end, if you want responsive geometry, you will end up writing those scripts anyway.  The only thing missing being the default init props for the control (which we normally would create in the IDE) so one must as well "create button" and set the default init buttons in the script. Actually it would be pretty easy to create the button in WSIWIG and have a small tool to write out the initial props that you could then turn into a script.

But this should probably be different thread.  I'm sure HQ has solved moved of these issues, but we may need to wait until LC9 is unveiled before we get the full picture from the mother ship, until then… I "muddle along"

Brahmanathaswami



_______________________________________________
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: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
On the subject of building UI from script, I generally think it boils down
to whether you already have a good resizeStack handler implemented.  If you
do, you've done all the hard work already - you can just create all the
objects with their required properties before the card opens and delete
them when it closes, and your resizeStack does the rest of the placement
work.

Obviously this is a bit trickier if you have a lot of fields prepopulated
with text, or groups with more complicated structure where it's not so easy
to tease out the scripts into a behavior.

On Sun, Feb 5, 2017 at 6:03 PM Sannyasin Brahmanathaswami via use-livecode <
[hidden email]> wrote:

> Trevor, thanks for that intro to the new tools in LC9
>
>
> I'm already using libraries and behaviors extensively, but still find my
> self build LC stack binaries with a full stack script or, quite often,  95%
> of the code in the card script (if the UI can all be done on a single card)
>
> The other day I was thinking 'gee, why not just move this card script out
> to a behavior and assign it to the card."  been mulling this over for a few
> days, the the work flow for making this transition seemed onerous, but LC9
> will make it soooo easy!
>
> Our new app, SivaSiva, is being done with GIT and this is the first time
> working with GIT for something like this… for web and RevIgniter, GIT make
> obvious sense, since the whole environment is text files from the ground up.
>
> But now, with the new app, we have this mix of text only scripts and
> binary *.livecode stacks.
>
> So this leads to two more interesting avenue of adventure/explorations
>
> 1) we are already hitting GIT conflicts with the main stack of the project
> because if one developer needs to add some stack files, or wants to change
> a standalone setting for testing a build on a device, the IDE of course
> requires a Save… so now this stack must be either stashed (assuming you
> don’t need the changes) or committed.. and we hit a conflict later that is
> not so easily resolved.
>
> 2) building UI from script: every now and the notion passes by that
> perhaps building UI from script has advantages of  the LC WSIWIG model. I
> was  intrigued in your to see in the background in sublime text, you had a
> handler that built some of the UI.  perhaps all of it for that dialog box?
> So the question then becomes when, where and why do we make a decision to
> go the route to build UI by script? I guess the one obvious answer is that
> you want to put the UI under git control so that we have, as you put it
> "fine-grained control over changes, edits, history" etc.
>
> I wonder if there are other criteria besides that. Possibly building UI be
> script may be better suited to responsive design, since, in the end, if you
> want responsive geometry, you will end up writing those scripts anyway.
> The only thing missing being the default init props for the control (which
> we normally would create in the IDE) so one must as well "create button"
> and set the default init buttons in the script. Actually it would be pretty
> easy to create the button in WSIWIG and have a small tool to write out the
> initial props that you could then turn into a script.
>
> But this should probably be different thread.  I'm sure HQ has solved
> moved of these issues, but we may need to wait until LC9 is unveiled before
> we get the full picture from the mother ship, until then… I "muddle along"
>
> Brahmanathaswami
>
>
>
> _______________________________________________
> 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: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
Heh, I somehow missed the para where you made this comment already Brahma!
Sorry.

On Sun, Feb 5, 2017 at 6:21 PM Ali Lloyd <[hidden email]> wrote:

> On the subject of building UI from script, I generally think it boils down
> to whether you already have a good resizeStack handler implemented.  If you
> do, you've done all the hard work already - you can just create all the
> objects with their required properties before the card opens and delete
> them when it closes, and your resizeStack does the rest of the placement
> work.
>
> Obviously this is a bit trickier if you have a lot of fields prepopulated
> with text, or groups with more complicated structure where it's not so easy
> to tease out the scripts into a behavior.
>
>
> On Sun, Feb 5, 2017 at 6:03 PM Sannyasin Brahmanathaswami via use-livecode
> <[hidden email]> wrote:
>
> Trevor, thanks for that intro to the new tools in LC9
>
>
> I'm already using libraries and behaviors extensively, but still find my
> self build LC stack binaries with a full stack script or, quite often,  95%
> of the code in the card script (if the UI can all be done on a single card)
>
> The other day I was thinking 'gee, why not just move this card script out
> to a behavior and assign it to the card."  been mulling this over for a few
> days, the the work flow for making this transition seemed onerous, but LC9
> will make it soooo easy!
>
> Our new app, SivaSiva, is being done with GIT and this is the first time
> working with GIT for something like this… for web and RevIgniter, GIT make
> obvious sense, since the whole environment is text files from the ground up.
>
> But now, with the new app, we have this mix of text only scripts and
> binary *.livecode stacks.
>
> So this leads to two more interesting avenue of adventure/explorations
>
> 1) we are already hitting GIT conflicts with the main stack of the project
> because if one developer needs to add some stack files, or wants to change
> a standalone setting for testing a build on a device, the IDE of course
> requires a Save… so now this stack must be either stashed (assuming you
> don’t need the changes) or committed.. and we hit a conflict later that is
> not so easily resolved.
>
> 2) building UI from script: every now and the notion passes by that
> perhaps building UI from script has advantages of  the LC WSIWIG model. I
> was  intrigued in your to see in the background in sublime text, you had a
> handler that built some of the UI.  perhaps all of it for that dialog box?
> So the question then becomes when, where and why do we make a decision to
> go the route to build UI by script? I guess the one obvious answer is that
> you want to put the UI under git control so that we have, as you put it
> "fine-grained control over changes, edits, history" etc.
>
> I wonder if there are other criteria besides that. Possibly building UI be
> script may be better suited to responsive design, since, in the end, if you
> want responsive geometry, you will end up writing those scripts anyway.
> The only thing missing being the default init props for the control (which
> we normally would create in the IDE) so one must as well "create button"
> and set the default init buttons in the script. Actually it would be pretty
> easy to create the button in WSIWIG and have a small tool to write out the
> initial props that you could then turn into a script.
>
> But this should probably be different thread.  I'm sure HQ has solved
> moved of these issues, but we may need to wait until LC9 is unveiled before
> we get the full picture from the mother ship, until then… I "muddle along"
>
> Brahmanathaswami
>
>
>
> _______________________________________________
> 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: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
In reply to this post by Mike Kerner via use-livecode
Ali, thanks for chiming in… in the current app we stayed away from any resizing, the Design passed down from our team which has years of experience in print graphics (but zero in digital UX/UI) would have been a challenge to get responsive. It could be done of course, anything can be done in Livecode!  But, compared to using CSS for web, writing all the code for making the design I got handed, responsive, would have taken more time than we wanted to put in at that stage of the project (with "tiny" budget!)… possibly in the future.  

RE: "a good resizeStack Handler" … it would be great is those who have mastered this skill--have libraries, examples… were to place them somewhere for us to study.

A lot of the "flak" I hear about using LC is "but it's not responsive, at that so easy with HTML5"   They gloss over the depth of javascript skills required to actually program the UI to do anything other than look pretty. However easy it may be to make a <div class="flexFrame"> and apply a class. The "ease" ends there.  If I have a UI ready to go and ask a JS jockey to program the whole UX, click a stop watch and have Jacqueline do it in LiveCode. Jacque will be done in half the time.

Point: if we had a more robust set of examples, lessons, youTube Tutorials on "building responsive UI for LiveCode" it would go a long way in helping the product feel that this issue, is a non-issue. Right now it is.

BR
 

On 2/5/17, 8:21 AM, "use-livecode on behalf of Ali Lloyd via use-livecode" <[hidden email] on behalf of [hidden email]> wrote:

    On the subject of building UI from script, I generally think it boils down
    to whether you already have a good resizeStack handler implemented.  If you
    do, you've done all the hard work already - you can just create all the
    objects with their required properties before the card opens and delete
    them when it closes, and your resizeStack does the rest of the placement
    work.
   
    Obviously this is a bit trickier if you have a lot of fields prepopulated
    with text, or groups with more complicated structure where it's not so easy
    to tease out the scripts into a behavior.

_______________________________________________
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: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
In reply to this post by Mike Kerner via use-livecode
ieOn Sun, Feb 5, 2017 at 12:03 PM, Sannyasin Brahmanathaswami via
use-livecode <[hidden email]> wrote:

>
> 2) building UI from script: every now and the notion passes by that
> perhaps building UI from script has advantages of  the LC WSIWIG model. I
> was  intrigued in your to see in the background in sublime text, you had a
> handler that built some of the UI.  perhaps all of it for that dialog box?
> So the question then becomes when, where and why do we make a decision to
> go the route to build UI by script? I guess the one obvious answer is that
> you want to put the UI under git control so that we have, as you put it
> "fine-grained control over changes, edits, history" etc.
>

Personally I don't like building UI from script and I very rarely do it in
my projects. The code you saw probably set properties of the controls that
already existed on the card. I prefer to lay out the UI in the LiveCode
IDE. With Levure adding stack files won't cause any conflicts. Each stack
is an independent file and the file that specifies which stacks to load is
a text file. If I am testing standalone settings then I do my testing and
then reset the file to the last commit. No need to stash the changes or
commit them.

My hope is that at some point LC will get a single file, text based file
format for stacks that can be used while authoring. My goal is to keep the
"live" aspect of LiveCode while gaining the benefits of version control
software and really powerful text editors. If I'm creating controls in
script I have to recreate the stack each time I want to move a control
around or add a control.


> I wonder if there are other criteria besides that. Possibly building UI be
> script may be better suited to responsive design, since, in the end, if you
> want responsive geometry, you will end up writing those scripts anyway.
> The only thing missing being the default init props for the control (which
> we normally would create in the IDE) so one must as well "create button"
> and set the default init buttons in the script. Actually it would be pretty
> easy to create the button in WSIWIG and have a small tool to write out the
> initial props that you could then turn into a script.
>

Whether or not you create your UI in script won't affect the code you would
write to make a design responsive. Creating responsive UI in LiveCode isn't
that difficult. If you look at your design you can probably splice it up
into rectangles. If my UI is made up of four primary rectangles then I have
four primary groups. My card script resizes those four groups. The
resizeControl handler in each group is responsible for resizing the
controls in that particular group. Within each primary group you can
continue to splice up the contents into more rectangles, creating groups
and writing more resizeControl handlers. I find that this approach makes
the resizing code more manageable as there is less code at each level.

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

Re: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
In line
On 2/5/17, 3:41 PM, "use-livecode on behalf of Trevor DeVore via use-livecode" <[hidden email] on behalf of [hidden email]> wrote:

     With Levure adding stack files won't cause any conflicts. Each stack
    is an independent file and the file that specifies which stacks to load is
    a text file.


BR: I must be missing something. in the video you show how the stack files of the URL Dialog stack have been set in the stack properties of the binary livecode stack…so if those changed, the binary is changed Y/N?

but here you say

"and the file that specifies which stacks to load is a text file."

 If I am testing standalone settings then I do my testing and
    then reset the file to the last commit.

BR: Oh… I should learn that one (GIT newbie here, barely crawling)

No need to stash the changes or
    commit them.

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

Re: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
I personally don't like everything in one file.  I conceptualize things
better if I can think of them as being separate.  When I'm building
interfaces, I could lay everything out on one card and use groups to
show/hide the relevant controls, but in my head they're all still there.
In interfaces that have overlays, I am constantly fighting the clutter that
I imagine in my head.  The new PB, without thumbnails, just makes that
issue worse for me.

Maybe that's part of the reason that I want implicit typing and I don't
like explicit variable declarations - it's more clutter to me.  Even in
Trevor's demo, the folder upon folder layout gets to me as being a jumble.
I completely understand why doing things this way can be a good idea, and
for IDE components, I even tend to agree that it is desirable, but for
projects that are not live, I still want something cleaner.

On Sun, Feb 5, 2017 at 10:00 PM, Sannyasin Brahmanathaswami via
use-livecode <[hidden email]> wrote:

> In line
> On 2/5/17, 3:41 PM, "use-livecode on behalf of Trevor DeVore via
> use-livecode" <[hidden email] on behalf of
> [hidden email]> wrote:
>
>      With Levure adding stack files won't cause any conflicts. Each stack
>     is an independent file and the file that specifies which stacks to
> load is
>     a text file.
>
>
> BR: I must be missing something. in the video you show how the stack files
> of the URL Dialog stack have been set in the stack properties of the binary
> livecode stack…so if those changed, the binary is changed Y/N?
>
> but here you say
>
> "and the file that specifies which stacks to load is a text file."
>
>  If I am testing standalone settings then I do my testing and
>     then reset the file to the last commit.
>
> BR: Oh… I should learn that one (GIT newbie here, barely crawling)
>
> No need to stash the changes or
>     commit them.
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
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: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
In reply to this post by Mike Kerner via use-livecode
On Sun, Feb 5, 2017 at 9:00 PM, Sannyasin Brahmanathaswami via use-livecode
<[hidden email]> wrote:

> In line
> On 2/5/17, 3:41 PM, "use-livecode on behalf of Trevor DeVore via
> use-livecode" <[hidden email] on behalf of
> [hidden email]> wrote:
>
>      With Levure adding stack files won't cause any conflicts. Each stack
>     is an independent file and the file that specifies which stacks to
> load is
>     a text file.
>
> BR: I must be missing something. in the video you show how the stack files
> of the URL Dialog stack have been set in the stack properties of the binary
> livecode stack…so if those changed, the binary is changed Y/N?
>

Correct. The stackfiles property is only changed if you add a new behavior
via a script only stack. That should only happen if you add a new control
to the stack that requires a behavior. Keep in mind that the URL Dialog is
a stack file that contains a single stack, no substacks. It represents one
window in the UI of the application.


> but here you say
>
> "and the file that specifies which stacks to load is a text file."
>

I'm referring to the app.yml file here. The app.yml file is what ties
together all of the files in the application folder into a single
application. It is where you specify which libraries, frontscripts,
backscripts, and other stacks make up the application. If I add a new UI
stack named "Prompt User Prior to Delete" no other stack files will be
modified. The only file that might be updated is the app.yml file and that
is unlikely as well. In the app.yml file you can specify that the contents
of a specific folder are components and Levure will treat all of the
contents of that folder as such.

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

Re: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
@ trevor:  OK, understood. In fact we are doing a similar/ almost same thing though calling it "SivaSiva.json"  which is read on start up,

re the stack files for the components: interesting…

We have been adding *all* behaviors for all modules in the main stack, since many of these are reused by controls in different modules/components, but I can see if we externalize the *entire* stack script of a component as a behavior then, your layout is obviously the way to do it. Thanks for that! I have been thinking about this already this past week and wasn't clear, Levure shows the way forward… I’ll download 9 asap.

@ Mike

I think we may not be on the same page. There is certainly no "one file" for the entire project. Both in our SivaSiva app we have many "modules" aka "components" in Trevor's framework ("views" in a MVC way of looking at it) … OTOH  some modules benefit by having one more UI's on the same card, or at least different cards in the same stack.

Yeah.. I use to worry about the array of folder and files, but believe me, we have it pretty straight forward. Trevor's Levure and our new app are surprisingly close. Actually Ralf's RevIgniter was there way ahead of us…

 if you think about it there are only a few classes of objects, so you don't have to make it too complex:

assets # images, sound, text files, video, info files.
behaviors # code you may want to assign to controls in many different contexts
config # start up defaults store as plain text/json/yaml/ LC arrays whatever…
libraries # code you want accessible everywhere all the time.
models  # re-usable code for doing "work/jobs"
modules  (aka components or "views")  # stacks users actually see
SuperApp.livecode # the "loader" stack

I don't think that is too much of a "jumble"  doesn't it add some obvious clarity?  If you want to "see" your app, open the components folder that's where the UI/views lives.… and this kind of frame work has a strong track record in web apps, CodeIgniter (PHP)  so it is well proven for usability.  

Anyway, the ability to diff previous commits and cross reference and "cherry pick" from other  branches has already saved me headaches in so many ways I can't ever go back.

AS for scary jumble snake pit, just expand some html5 apps, some of them are *really* scary. I unwrapped a Ionic app last month done in Angular2; it has 20,000+ files! Yikes! Of course this is like seeing the entire LC engine IDE files set right alongside your own, but with LiveCode we don’t' have to do that.

BR

On 2/5/17, 6:04 PM, "use-livecode on behalf of Trevor DeVore via use-livecode" <[hidden email] on behalf of [hidden email]> wrote:

    I'm referring to the app.yml file here. The app.yml file is what ties
    together all of the files in the application folder into a single
    application. It is where you specify which libraries, frontscripts,
    backscripts, and other stacks make up the application. If I add a new UI
    stack named "Prompt User Prior to Delete" no other stack files will be
    modified. The only file that might be updated is the app.yml file and that
    is unlikely as well. In the app.yml file you can specify that the contents
    of a specific folder are components and Levure will treat all of the
    contents of that folder as such.
   
   

_______________________________________________
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: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
In reply to this post by Mike Kerner via use-livecode
+1

The whole point, or one of the points to object oriented development was to de-centralize the code base. As stated in other posts it really comes down to how complex your app is. I have cards that can be used in any stack, and cards that are very specific to the app. Same with different stacks.

Bob S


On Feb 5, 2017, at 19:52 , Mike Kerner via use-livecode <[hidden email]<mailto:[hidden email]>> wrote:

I personally don't like everything in one file.  I conceptualize things
better if I can think of them as being separate.  When I'm building
interfaces, I could lay everything out on one card and use groups to
show/hide the relevant controls, but in my head they're all still there.
In interfaces that have overlays, I am constantly fighting the clutter that
I imagine in my head.  The new PB, without thumbnails, just makes that
issue worse for me.

_______________________________________________
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: Converting scripts in stacks to script only stack behaviors

Mike Kerner via use-livecode
In reply to this post by Mike Kerner via use-livecode
Sannyasin Brahmanathaswami wrote:

 > A lot of the "flak" I hear about using LC is "but it's not
 > responsive, at that so easy with HTML5"   They gloss over the
 > depth of javascript skills required to actually program the UI
 > to do anything other than look pretty. However easy it may be
 > to make a <div class="flexFrame"> and apply a class. The "ease"
 > ends there.

Well said.  "Responsive" isn't a technology, but a design decision
(these days, arguably a requirement).  Regardless of the language used,
decisions need to be made, and the expression of those decisions in code
needs to be tested.

Some things are easier in one language than another, and other things
easier in other languages.

But all of them require commitment to providing a good UX, clear
thinking about the layout goals, and good familiarity with whatever
language will be used to express those goals.


 > Point: if we had a more robust set of examples, lessons, youTube
 > Tutorials on "building responsive UI for LiveCode" it would go
 > a long way in helping the product feel that this issue, is a
 > non-issue. Right now it is.

Personally, when it comes to programming I prefer textual tutorials, so
I can copy-and-paste code.  But any tutorials folks in our community
want to deliver would be welcome.

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