Re: Helping newcomers anticipate that standalones can't save to themselves
Le 15 août 2014 à 16:13, Richard Gaskin ambassa...@fourthworld.com a écrit : One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start Hello, What about a « test » mode that simulate the standalone comportment ? ___ 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: Helping newcomers anticipate that standalones can't save to themselves
Yes, I like the idea of a test mode. I prefer that my experience in the development environment match the final user experience as closely as possible. I can imagine linking this test mode to what are now the View Look and Feel Emulated... menu items. And of course it would be great to have those Look and Feel menu items include iOS and Android... and updated from Mac OS Classic to OS X, and Windows 95 to something more current. On 15 Aug 2014, at 9:21 AM, Ludovic THEBAULT ludovic.theba...@laposte.net wrote: Le 15 août 2014 à 16:13, Richard Gaskin ambassa...@fourthworld.com a écrit : One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start Hello, What about a « test » mode that simulate the standalone comportment ? ___ 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 -- Charles E. Buchwald CEO/Director General Museografica Digital http://digital.museografica.com Mac OSX 10.9.4, LC 6.6.2 Commercial LC Developer Tools: http://buchwald.ca/developer-tools/ Email Notice: http://wp.me/P3aT4d-33 ___ 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: Helping newcomers anticipate that standalones can't save to themselves
hmmm… it would be too much to ask that the test mode could simulate the windows environment on a Mac and vis versa. Fairly impossible I suppose to emulate Linux… Bob S On Aug 15, 2014, at 07:21 , Ludovic THEBAULT ludovic.theba...@laposte.netmailto:ludovic.theba...@laposte.net wrote: Le 15 août 2014 à 16:13, Richard Gaskin ambassa...@fourthworld.commailto:ambassa...@fourthworld.com a écrit : One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start Hello, What about a « test » mode that simulate the standalone comportment ? ___ use-livecode mailing list use-livecode@lists.runrev.commailto: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: Helping newcomers anticipate that standalones can't save to themselves
Hi Richard Although I have not seen this occur in stacks I've created, I would like to better understand where you are going with this topic? Are you starting a new way to address specific issues with LiveCode, or suggesting changes to the IDE? Thank you Vaughn Clement Apps by Vaughn Clement (Support) *http://www.appsbyvaughnclement.com/tools/home-page/ http://www.appsbyvaughnclement.com/tools/home-page/* Skype: vaughn.clement https://secure.join.me/appsbyvclement FaceTime: vclem...@gmail.com LogMeIn also avaialble Call on ooVoo at address: vaughnclement or 9282549062 Ph. 928-254-9062 On Fri, Aug 15, 2014 at 7:13 AM, Richard Gaskin ambassa...@fourthworld.com wrote: One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Helping newcomers anticipate that standalones can't save to themselves
How about going the other direction and fixing the behavior? Technically, any standalone CAN edit itself, anyway, but there are all sorts of things that might be able to be done with ancillary files to store changes/updates. When the standalone is going to set something, it checks the file (like a settings file), first. This is just like what happens with the message path. Polymorphism will make the product more powerful and let people do amazing things with it. On Fri, Aug 15, 2014 at 10:58 AM, Bob Sneidar bobsnei...@iotecdigital.com wrote: hmmm… it would be too much to ask that the test mode could simulate the windows environment on a Mac and vis versa. Fairly impossible I suppose to emulate Linux… Bob S On Aug 15, 2014, at 07:21 , Ludovic THEBAULT ludovic.theba...@laposte.net mailto:ludovic.theba...@laposte.net wrote: Le 15 août 2014 à 16:13, Richard Gaskin ambassa...@fourthworld.com mailto:ambassa...@fourthworld.com a écrit : One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start Hello, What about a « test » mode that simulate the standalone comportment ? ___ use-livecode mailing list use-livecode@lists.runrev.commailto: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 -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, This is good. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Helping newcomers anticipate that standalones can't save to themselves
From my own point of view, I struggled trying to understand some of the basic principles of using LC (Revolution as it was then), until I finally picked apart some sample stacks such as the calculator etc., then a few things started to fall in to place. After that I looked for stacks that had a similar use or techniques to the project I wanted to build (I still do to an extent), to find ideas and learn about how LC works in ways that I maybe don't know or understand. My biggest frustration at the time was the disjointed documentation and lack of structured tutorials, many people have also made the same comments over the years. I feel the tutorials especially have improved and the documentation is improving slowly. Thinking back to when I discovered that I needed an anchor window (or splash screen), again I had to do more research to find out what was needed until I eventually understood the reasons and principles behind this process. Maybe this could be addressed with a good, well structured My First Application tutorial that ships with each new user download, or a package that's easily visible and readily available for new users to download. Currently there is just a free mobile template that tries to entice users to download the community version. I'm sure there are enough teachers and ex-teachers on this list that could maybe help with this. A well structured tutorial can help to guide the new user with the right techniques from the start. Moving forward from the anchor window (or splash screen), I also feel a series of basic project templates (or starting points) could be useful, not as complex as the GLX framework, but something that already has an anchor window, preferences, menu bar and a few basic (commented) scripts for printing, saving etc. Obviously these templates would be different for desktop, mobile or tablet, but starting from a template rather than a single empty stack would eventually help to guide the new user towards a better understanding of the techniques needed for each platform. Paul On 2014-08-15, at 7:13 AM, Richard Gaskin ambassa...@fourthworld.com wrote: One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Helping newcomers anticipate that standalones can't save to themselves
Hi Richard This is a good opening topic that can solicit comments. I have passed through the frustration about documentation already, and I find I live on the How To email to find answers. The forums seem to take forever to get answers. Considering that the How To offers a good reference platform, wouldn't make sense to build on the knowledgebase of the How to to provide for a more organized reference tool? Can the How to be improved like the forum where topics are simpler to locate using a category and keywords. I've used the current system for the How to listings and I have found it difficult to find answers based on the current search approach. Thank you Vaughn Clement Apps by Vaughn Clement (Support) *http://www.appsbyvaughnclement.com/tools/home-page/ http://www.appsbyvaughnclement.com/tools/home-page/* Skype: vaughn.clement https://secure.join.me/appsbyvclement FaceTime: vclem...@gmail.com LogMeIn also avaialble Call on ooVoo at address: vaughnclement or 9282549062 Ph. 928-254-9062 On Fri, Aug 15, 2014 at 8:28 AM, Paul Hibbert paulhibb...@mac.com wrote: From my own point of view, I struggled trying to understand some of the basic principles of using LC (Revolution as it was then), until I finally picked apart some sample stacks such as the calculator etc., then a few things started to fall in to place. After that I looked for stacks that had a similar use or techniques to the project I wanted to build (I still do to an extent), to find ideas and learn about how LC works in ways that I maybe don't know or understand. My biggest frustration at the time was the disjointed documentation and lack of structured tutorials, many people have also made the same comments over the years. I feel the tutorials especially have improved and the documentation is improving slowly. Thinking back to when I discovered that I needed an anchor window (or splash screen), again I had to do more research to find out what was needed until I eventually understood the reasons and principles behind this process. Maybe this could be addressed with a good, well structured My First Application tutorial that ships with each new user download, or a package that's easily visible and readily available for new users to download. Currently there is just a free mobile template that tries to entice users to download the community version. I'm sure there are enough teachers and ex-teachers on this list that could maybe help with this. A well structured tutorial can help to guide the new user with the right techniques from the start. Moving forward from the anchor window (or splash screen), I also feel a series of basic project templates (or starting points) could be useful, not as complex as the GLX framework, but something that already has an anchor window, preferences, menu bar and a few basic (commented) scripts for printing, saving etc. Obviously these templates would be different for desktop, mobile or tablet, but starting from a template rather than a single empty stack would eventually help to guide the new user towards a better understanding of the techniques needed for each platform. Paul On 2014-08-15, at 7:13 AM, Richard Gaskin ambassa...@fourthworld.com wrote: One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your
Re: Helping newcomers anticipate that standalones can't save to themselves
Vaughn Clement wrote: Hi Richard Although I have not seen this occur in stacks I've created, I would like to better understand where you are going with this topic? Are you starting a new way to address specific issues with LiveCode, or suggesting changes to the IDE? That's a good question, and to be honest I'm not really sure, just exploring options. I kinda like the idea of a runtime emulator, but even if we could build such a thing that can account for the many platform-specific things it would need to be useful, we're still left with the same need: If a person is able to know that they need to run a tool to discover the implications of not being able to save to a standalone, the existing Standalone Builder provides that. The trick is being able to know that this sort of evaluation has to be done at all. Extending the documentation might be useful, but only to the degree that any new additions will be read. We could add all sorts of additional tutorials and such, but this issue is already described in a very bold callout on the User Guide page that discusses standalones (p 299). If users aren't reading the primary source of information on using LiveCode, what assurances can we have that they'll discover any other discussion of this in some separate tutorial? Mike's very inventive, and I like where he's going with this: How about going the other direction and fixing the behavior? Technically, any standalone CAN edit itself, anyway, but there are all sorts of things that might be able to be done with ancillary files to store changes/updates. When the standalone is going to set something, it checks the file (like a settings file), first. One of the challenges with such an approach is that people use LiveCode in a wide variety of ways, and in a few cases may rely on data being cleared when the standalone is exited. So maybe such a behavior could be limited to attempting to use a save command on a standalone, in which it automatically clones that stack? But then where would it be saved? How would it know whether it should be in the Documents folder, or Prefs, or App Support, or some other place? Taking a broader view, for most apps it's not desirable to save UI elements at all, populating the UI with data stored externally instead, so when you deploy upgrades the new UI can display older data without having to worry about the old UI. And for separate data storage there are many options, from text files to custom properties to XML to JSON to databases and more - which one is the right fit for the application at hand? Currently these are decisions we make, and once we understand that OSes don't allow executables to write to themselves we design with this in mind, and often enjoy the flexibility of having so many different options for managing persistence. In our local user group we kicked around some ideas for handling this, but it didn't take long until what we were leaning toward was a sort of framework. But as useful as frameworks can be they can also be limiting, and require learning even more to be able to do productive work since we have to learn both LiveCode and the specific ways LiveCode is used within the framework. It's an odd problem, in that it's simple enough to accommodate once the need is known, but difficult to know it's needed in advance. I used to think that this expectation that standalones might be able to save to themselves was limited to those with HyperCard experience, since AFAIK Mac Classic (by virtue of its resource fork) was the only OS in popular use that ever allowed this. And given that both HC and Mac Classic were killed off more than a decade ago, I would have expected this issue to come up ever less often since. Yet somehow even among young people, who've never used HC and in a world where they've never seen any application save to itself, find themselves with the expectation that this should be doable. Not sure how that expectation happens, or how to prevent it, but it comes up just often enough that I think it may be worth trying. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Helping newcomers anticipate that standalones can't save to themselves
Maybe having a saving data/reading data example stack included among the default LC splash screen examples could be an additional learning avenue. The demo stack could dynamically generate a data stack in the system's Documents folder (for ease of writing/locating), as opposed to requiring the developer to manually place any files/folders. Regards, Scott Rossi Creative Director Tactile Media UX/UI Design On Aug 15, 2014, at 9:20 AM, Richard Gaskin ambassa...@fourthworld.com wrote: We could add all sorts of additional tutorials and such, but this issue is already described in a very bold callout on the User Guide page that discusses standalones (p 299). If users aren't reading the primary source of information on using LiveCode, what assurances can we have that they'll discover any other discussion of this in some separate tutorial? ___ 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: Helping newcomers anticipate that standalones can't save to themselves
On Aug 15, 2014, at 7:13 AM, Richard Gaskin ambassa...@fourthworld.com wrote: One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start? I would think that this could be solved with a document titled something like: “Things you should know…” or “Getting Started” or “Read Me Before Starting” or something entirely different. This document should be in the ‘User Guide’ and the intro screen that pops up for the first few times when LC is started. It might be a useful Blog of things to know about LC when starting for the first time. It should be in a document on the website in the documentation area as well. Bonus points for checking for the following in the script editor on compile and then popping up a dialog that states “Did you know…” or “this code will not work as in a standalone”. Best regards, Mark Talluto CanelaSoftware.com LiveCloud.io ___ 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: Helping newcomers anticipate that standalones can't save to themselves
On Fri, Aug 15, 2014 at 9:20 AM, Richard Gaskin ambassa...@fourthworld.com wrote: Yet somehow even among young people, who've never used HC and in a world where they've never seen any application save to itself, find themselves with the expectation that this should be doable. It's what people new to programming (yet are frequent users) expect in an app today, with apps like Final Cut Pro X , iTunes, iPad, most Apple OEM apps requiring no 'saving'. Thanks go to apple, although I'm sure this is the way android apps are expected to work too. These folks may not have a concept of saving anything or worse, WHERE is being saved... All these apps go out of their way to obfuscate the location of discrete files 'so we won't have to worry our pretty little head' about them. Drives me nuts. Is Windoze/MS going that direction? *--* *Stephen Barncard - San Francisco Ca. USA - Deeds Not Words* ___ 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: Helping newcomers anticipate that standalones can't save to themselves
Mark Talluto wrote: I would think that this could be solved with a document titled something like: “Things you should know…” or “Getting Started” or “Read Me Before Starting” or something entirely different. Along those lines, earlier this morning I took a look through the various introductory materials linked to in the Help menu and filed this request to add the warning that appears on p 299 of the User Guide to the Getting Started materials on the web which perhaps may be read more frequently, which might explain why the User Guide's effort to cover this has fallen flat: http://quality.runrev.com/show_bug.cgi?id=13194 -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Helping newcomers anticipate that standalones can't save to themselves
I use the launcher/updater with the script/data stack model so my standalones can save changes into it’s stacks. Wonder if it would make sense to have a standard version of that launcher/updater so that newbies can just grab it and use it. Kee On Aug 15, 2014, at 7:13 AM, Richard Gaskin ambassa...@fourthworld.com wrote: One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Helping newcomers anticipate that standalones can't save to themselves
Would it be possible for the standalone builder to automatically create an .exe stack that opens invisibly and does only one thing: opens what the user has presented as the mainstack? Then things would work exactly the same as in the IDE and changes made to the mainstack would be saved. Some attention would have to be paid to not messing up the message path, I guess, but it seems feasible on the face of it. (Of course, lots of things seem feasible when you don't really know what you're talking about….) -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Aug 15, 2014, at 10:13 AM, Richard Gaskin wrote: One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Helping newcomers anticipate that standalones can't save to themselves
Late to this, but I like the Mark T thought idea. I still remember when the datagrid first came out, one specific part of the documentation was a big bold link that said something like.. What things do I need to know to avoid needless headaches.. It included things like building a standalone/splashstack combination, and putting a fake datagrid stub substack as part of the splash so that the builder would know to included the datagrid stuff. If a list of such things could be put together and shown on first run, it might be a just the ticket. On Fri, Aug 15, 2014 at 11:46 AM, Peter M. Brigham pmb...@gmail.com wrote: Would it be possible for the standalone builder to automatically create an .exe stack that opens invisibly and does only one thing: opens what the user has presented as the mainstack? Then things would work exactly the same as in the IDE and changes made to the mainstack would be saved. Some attention would have to be paid to not messing up the message path, I guess, but it seems feasible on the face of it. (Of course, lots of things seem feasible when you don't really know what you're talking about….) -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig On Aug 15, 2014, at 10:13 AM, Richard Gaskin wrote: One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Helping newcomers anticipate that standalones can't save to themselves
This would be awesome, Kee. I've been looking for something like that, myself. (Do you have anything you would be willing to share off list?) Not to bring up a sore subject, but something like this would be pretty easy to share and distribute... and might even be found by new users more easily... if revOnline was fixed up... and included a basics or new users and/or templates tag or category. - Charles On 15 Aug 2014, at 12:46 PM, kee nethery k...@kagi.com wrote: I use the launcher/updater with the script/data stack model so my standalones can save changes into it’s stacks. Wonder if it would make sense to have a standard version of that launcher/updater so that newbies can just grab it and use it. Kee -- Charles E. Buchwald CEO/Director General Museografica Digital http://digital.museografica.com Mac OSX 10.9.4, LC 6.6.2 Commercial LC Developer Tools: http://buchwald.ca/developer-tools/ Email Notice: http://wp.me/P3aT4d-33 ___ 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: Helping newcomers anticipate that standalones can't save to themselves
I like this idea a lot! Roger On Aug 15, 2014, at 10:46 AM, kee nethery k...@kagi.com wrote: I use the launcher/updater with the script/data stack model so my standalones can save changes into it’s stacks. Wonder if it would make sense to have a standard version of that launcher/updater so that newbies can just grab it and use it. Kee On Aug 15, 2014, at 7:13 AM, Richard Gaskin ambassa...@fourthworld.com wrote: One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide. Clearly something more is needed. What should that be? Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things. How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Helping newcomers anticipate that standalones can't save to themselves
kee nethery wrote: I use the launcher/updater with the script/data stack model so my standalones can save changes into it’s stacks. Wonder if it would make sense to have a standard version of that launcher/updater so that newbies can just grab it and use it. In a sense, that suggestion is for a type of application template, likely very much a good thing esp. when we consider how frequently folks mention that something they miss from HyperCard was its collection of prefab components. It may be worth pursuing, perhaps even as a community effort, which would allow us to have what we want right now without having to take resources away from the engine team. But if we were to go down the route, we'd probably want to deliver a collection of such templates rather than just one, so folks can better appreciate the many different ways LiveCode can be used, some of which are very important to use for some applications, while other methods are important for other apps. For example, while saving a stack file is convenient, it's only convenient for one version. If a future version of your app has an opportunity to display the data in a different UI, how do you update the UI when it's been saved in stacks made with an older version? In most languages there isn't much of an opportunity to save the UI with the data, or at least not as temptingly easy as it is in LC, so the common convention is to externalize data from its presentation, something most frameworks provide strong support for. For many apps externalizing data is only beneficial for future UI enhancements, and as useful as that is there's another set of considerations as well with LC: What do we do in circumstances where the collection of data if stored on cards may grow over time to a number of cards no longer practical in LC? Fortunately LC includes very strong database support, and at this point most of us who manage sizable collections of data use those or similar means of managing persistent data outside of our apps. But which storage method is best for the app you're working on right now? And will it be the best choice for the app you're working on tomorrow? Thinking about this with a breadth that admittedly may lend itself to oversimplification, we might think of apps as falling into three categories: - Utilities: usually a single window, no documents, and the only persistent data is prefs. A calculator is a good example. - Databases: usually a single window, though it may have secondary windows for specific views or tasks, which need prefs as well as a database file of some kind usually in a fixed location. iTunes, Address Book, and RhythmBox are good examples. - Document-centric: multiple windows in which each window is a view to data store in a separate file located in a place of the user's choosing. Word processors, spreadsheets, drawing programs, etc. So if we were to make templates, it may be helpful to make at least three. What other types might we need? And given the complexity inherent in maintaining the relationship between document files and the view of document data in a window, how might we do this simply in a way that avoids the complexity an high learning curve of a framework? And for all three types, we have both the opportunity and the risk (depending on whether you're an optimist or a pessimist g) of a much deeper issue: what's the simplest way to arrive at a generalized MVC pattern for LiveCode so we can manage the relationship between a data store and views of the data easily? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Helping newcomers anticipate that standalones can't save to themselves
Paul Hibbert wrote: My biggest frustration at the time was the disjointed documentation and lack of structured tutorials, many people have also made the same comments over the years. I feel the tutorials especially have improved and the documentation is improving slowly. Thinking back to when I discovered that I needed (...), again I had to do more research to find out what was needed until I eventually understood the reasons and principles behind this process. Maybe this could be addressed with a good, well structured My First Application tutorial that ships with each new user download, or a package that's easily visible and readily available for new users to download. Currently there is just a free mobile template that tries to entice users to download the community version. I'm sure there are enough teachers and ex-teachers on this list that could maybe help with this. A well structured tutorial can help to guide the new user with the right techniques from the start. I share this frustration, Paul. Lack of documentation, tutorials, and ready-to-reuse stacks is crippling; especially for newbies, but also for seasoned veterans of xTalk (like myself and many oldies on this list). It's my background in HyperCard+MetaCard, aka experience, that keeps my head-above-water. After a couple of months of experimentation, I have finally mastered LC's grep, but I'm still struggling with rev's XML (and with unicode too); no time yet to dig deep into data-grids, database connectivity, http messaging (LC as web client), etc. The lack of docs, tutorials and ready-to-reuse stacks are hampering process of training the pupil I'm currently training. If Runtime wants more users, and I'm sure they do, they would do well to address this ongoing issue. For my part I would be willing to craft some training tools and materials (ex: how-to match using regex), but time is cruelly-short at this time. Keep swimming ... you'll get to the other side! :) Alain On Friday, August 15, 2014 11:28:44 AM, Paul Hibbert paulhibb...@mac.com wrote: From my own point of view, I struggled trying to understand some of the basic principles of using LC (Revolution as it was then), until I finally picked apart some sample stacks such as the calculator etc., then a few things started to fall in to place. After that I looked for stacks that had a similar use or techniques to the project I wanted to build (I still do to an extent), to find ideas and learn about how LC works in ways that I maybe don't know or understand. My biggest frustration at the time was the disjointed documentation and lack of structured tutorials, many people have also made the same comments over the years. I feel the tutorials especially have improved and the documentation is improving slowly. Thinking back to when I discovered that I needed an anchor window (or splash screen), again I had to do more research to find out what was needed until I eventually understood the reasons and principles behind this process. Maybe this could be addressed with a good, well structured My First Application tutorial that ships with each new user download, or a package that's easily visible and readily available for new users to download. Currently there is just a free mobile template that tries to entice users to download the community version. I'm sure there are enough teachers and ex-teachers on this list that could maybe help with this. A well structured tutorial can help to guide the new user with the right techniques from the start. Moving forward from the anchor window (or splash screen), I also feel a series of basic project templates (or starting points) could be useful, not as complex as the GLX framework, but something that already has an anchor window, preferences, menu bar and a few basic (commented) scripts for printing, saving etc. Obviously these templates would be different for desktop, mobile or tablet, but starting from a template rather than a single empty stack would eventually help to guide the new user towards a better understanding of the techniques needed for each platform. Paul On 2014-08-15, at 7:13 AM, Richard Gaskin ambassa...@fourthworld.com wrote: One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks. Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause. So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or splash screen) pattern, or completely rewrite everything to use an external text file or database or what have you. The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining
Re: Helping newcomers anticipate that standalones can't save to themselves
Alain Farmer wrote: Lack of documentation, tutorials, and ready-to-reuse stacks is crippling; especially for newbies, but also for seasoned veterans of xTalk (like myself and many oldies on this list). It would be helpful if we could all take a really good look at what we have now to see if we can arrive at specific actionable recommendations to improve them. Looking just as the items included with the IDE install, the current inventory of learning materials includes: - 378-page User Guide PDF: true, its copyright date may make it seem old, but nearly every word of it is as relevant today as when it was written. And despite many requests here and elsewhere for specific reports against it, very few instances of truly erroneous information there have ever been reported. Better still: Dan Shafer has generously offered to lead an effort to do a thorough tech edit on this for v7, which I'll be helping with. The RunRev team has posted the Word source files to GitHub to get that started. If anyone here would like to help we'll be divvying up chapters soon, so drop me a note. - 78 tutorial stacks in the Resources window: covering a wide range of topics from working with images and databases to writing client- server apps like a chat client, they're not bad and many make a good starting point for one's own projects. We could add more, and it may be helpful to review the ones we have to determine which others we might want to see added to it. - 20 prefab components in the Object Library: this library is extensible, so we could make any number of new components to share. Which ones should we make? - Many dozens of supplemental tutorials and guides: linked to in the Help menu, these topics cover things like the nuances of working with the data grid, setting up LiveCode Server, and lots more. What other tutorials might we add to those? Looking at the scope of resources, obviously they could benefit from being collated into a single collection. Ben Beaumont is working on that now, and while I don't know the full status on that in terms of feature release dates I do know it's a keen interest of theirs and they're very open to engaging to community to expand on these things. So let's get what we want. Who's in a position to help with either crafting new learning materials, or joining in the forums to brainstorm ways to make the most of the learning materials we have? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Helping newcomers anticipate that standalones can't save to themselves
Okay, so let’s remember that a Dev Environment is an order of magnitude (or more) more complex that simply running an application. It’s an application that builds applications, for crying out loud, and people who take up software development need to get used to the idea that they are going to *have to* study up on the product. Try getting into Java or C without reading the documentation. Someone said that executables can modify themselves. Erm… no they cannot. If they can, then so can malware. Modern OS’es prevent this, and the very nature of an executable (and I mean the *actual* executable, not the package that contains it) will prevent this. Since the mainstack is compiled with the runtime engine to form the executable, well, that as they say, is that. C++ executables cannot modify themselves once compiled. They can modify other support files, but not themselves directly. I don’t understand why people expect Livecode to be different. All that being said, it *would* be nice to have an emulator that I can switch to so I can see how it will run on my Mac without having to switch to my Virtual Machine and run it in Livecode there. But that is because I am lazy. It’s not that much more trouble to bite the bullet and buy the VM software. As far as the documentation, that can always be improved. Bob S ___ 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: Helping newcomers anticipate that standalones can't save to themselves
In reply to : Taking a broader view, for most apps it's not desirable to save UI elements at all, populating the UI with data stored externally instead, so when you deploy upgrades the new UI can display older data without having to worry about the old UI. And for separate data storage there are many options, from text files to custom properties to XML to JSON to databases and more - which one is the right fit for the application at hand? I am currently programming my stacks as single-card front-ends that read/write XML/RDF files for the data of each card. The main reason that I am doing this, this way, is that I have over a million files to manage, which is way-too-much for LiveCode to handle as cards (one card per file). There are other benefits too: 1. separation of content and UI, 2. multiple views with custom datasets and UI; 3. open data is easy to share/migrate; 4. filesystem, OS and command-line become useful additions for my application; 5. there are thousands of tools and web-services to handle XML/RDF data, aka Open Data. I am also interested in JSON, because this is the native format of JavaScript, Couch, and MANY other tools. It is essential for inter-operability. Btw, Couch is a relatively-new no-SQL database, much faster than any SQL, designed for massive distributed systems, specialized in replication synchronization. Couch's API is native HTTP : HEAD, GET, POST, PUT, DELETE. Meanwhile, back at the LiveCode ranch, it would indeed be nice to be able to handle JSON, load it as an array and/or a graph. Is it the case already ? Alain On Friday, August 15, 2014 12:21:07 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Vaughn Clement wrote: Hi Richard Although I have not seen this occur in stacks I've created, I would like to better understand where you are going with this topic? Are you starting a new way to address specific issues with LiveCode, or suggesting changes to the IDE? That's a good question, and to be honest I'm not really sure, just exploring options. I kinda like the idea of a runtime emulator, but even if we could build such a thing that can account for the many platform-specific things it would need to be useful, we're still left with the same need: If a person is able to know that they need to run a tool to discover the implications of not being able to save to a standalone, the existing Standalone Builder provides that. The trick is being able to know that this sort of evaluation has to be done at all. Extending the documentation might be useful, but only to the degree that any new additions will be read. We could add all sorts of additional tutorials and such, but this issue is already described in a very bold callout on the User Guide page that discusses standalones (p 299). If users aren't reading the primary source of information on using LiveCode, what assurances can we have that they'll discover any other discussion of this in some separate tutorial? Mike's very inventive, and I like where he's going with this: How about going the other direction and fixing the behavior? Technically, any standalone CAN edit itself, anyway, but there are all sorts of things that might be able to be done with ancillary files to store changes/updates. When the standalone is going to set something, it checks the file (like a settings file), first. One of the challenges with such an approach is that people use LiveCode in a wide variety of ways, and in a few cases may rely on data being cleared when the standalone is exited. So maybe such a behavior could be limited to attempting to use a save command on a standalone, in which it automatically clones that stack? But then where would it be saved? How would it know whether it should be in the Documents folder, or Prefs, or App Support, or some other place? Taking a broader view, for most apps it's not desirable to save UI elements at all, populating the UI with data stored externally instead, so when you deploy upgrades the new UI can display older data without having to worry about the old UI. And for separate data storage there are many options, from text files to custom properties to XML to JSON to databases and more - which one is the right fit for the application at hand? Currently these are decisions we make, and once we understand that OSes don't allow executables to write to themselves we design with this in mind, and often enjoy the flexibility of having so many different options for managing persistence. In our local user group we kicked around some ideas for handling this, but it didn't take long until what we were leaning toward was a sort of framework. But as useful as frameworks can be they can also be limiting, and require learning even more to be able to do productive work since we have to learn both LiveCode and the specific ways LiveCode is used within the framework. It's an odd problem, in that it's simple enough to
Re: Helping newcomers anticipate that standalones can't save to themselves
Bob Sneidar wrote: All that being said, it *would* be nice to have an emulator that I can switch to so I can see how it will run on my Mac without having to switch to my Virtual Machine and run it in Livecode there. But that is because I am lazy. It’s not that much more trouble to bite the bullet and buy the VM software. Venturing just a tad OT here, but I feel obliged to share the good news Mark Wieder shared with me a few years ago: VirtualBox https://www.virtualbox.org/ Free as in both beer and freedom, in my experience it also outperforms Parallels rather dramatically in the time it takes to restore a session, and has pretty much all the modern features we've come to expect from such tools: - Your choice of single-window or interleaved modes - Wide range of hardware access and emulation options - Support for snapshots - Clipboard and shared folder integration - Very easy to use Thank you Mr. Wieder for turning me on that gem! -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Helping newcomers anticipate that standalones can't save to themselves
Alain Farmer wrote: I am also interested in JSON, because this is the native format of JavaScript, Couch, and MANY other tools. It is essential for inter-operability. Btw, Couch is a relatively-new no-SQL database, much faster than any SQL, designed for massive distributed systems, specialized in replication synchronization. Couch's API is native HTTP : HEAD, GET, POST, PUT, DELETE. Meanwhile, back at the LiveCode ranch, it would indeed be nice to be able to handle JSON, load it as an array and/or a graph. Is it the case already ? With CouchDB's main API being HTTP-based, do you know if there's a library for LC to make working with it even more convenient? As for JSON, there are several libraries that convert LC arrays to JSON and back again: http://revonline2.runrev.com/stack/82/LibJson-1-0b https://github.com/luxlogica/easyjson https://github.com/montegoulding/mergJSON http://www.rozek.mobi/LiveCode/JSONlib/index_scr_en.html -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Helping newcomers anticipate that standalones can't save to themselves
Thanks Richard. I tried that some time ago but it didn’t work with all apps. I suppose you are saying it will work with Livecode? I will give that a try! Bob S On Aug 15, 2014, at 12:31 , Richard Gaskin ambassa...@fourthworld.com wrote: Bob Sneidar wrote: All that being said, it *would* be nice to have an emulator that I can switch to so I can see how it will run on my Mac without having to switch to my Virtual Machine and run it in Livecode there. But that is because I am lazy. It’s not that much more trouble to bite the bullet and buy the VM software. Venturing just a tad OT here, but I feel obliged to share the good news Mark Wieder shared with me a few years ago: VirtualBox https://www.virtualbox.org/ Free as in both beer and freedom, in my experience it also outperforms Parallels rather dramatically in the time it takes to restore a session, and has pretty much all the modern features we've come to expect from such tools: - Your choice of single-window or interleaved modes - Wide range of hardware access and emulation options - Support for snapshots - Clipboard and shared folder integration - Very easy to use Thank you Mr. Wieder for turning me on that gem! -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Helping newcomers anticipate that standalones can't save to themselves
Hi All My first look at LC a year ago: Was it just me or do you find that many of the reference documents and media are not well written. As I have stated in the past, as a newbie I found the media incomplete and misleading in many areas. Today: Since that time I have come to understand that LiveCode is a horse of many colors and it does exist in the land of OZ. What is difficult to understand as a newbie is the vast number of things you can do with LiveCode. The scope of design approaches available and the way the design varies depending upon your expectations and ability to formulate the requirements. Looking forward: The transition period since the Kickstarter funding has been a big distraction for new users. Its hard to get started alone track the many versions and changes afoot. I am looking forward to a calmer time when you can see the results of your work and not having to deal with bugs and version issues. Thank you Vaughn Clement Apps by Vaughn Clement (Support) *http://www.appsbyvaughnclement.com/tools/home-page/ http://www.appsbyvaughnclement.com/tools/home-page/* Skype: vaughn.clement https://secure.join.me/appsbyvclement FaceTime: vclem...@gmail.com LogMeIn also avaialble Call on ooVoo at address: vaughnclement or 9282549062 Ph. 928-254-9062 On Fri, Aug 15, 2014 at 12:31 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Bob Sneidar wrote: All that being said, it *would* be nice to have an emulator that I can switch to so I can see how it will run on my Mac without having to switch to my Virtual Machine and run it in Livecode there. But that is because I am lazy. It’s not that much more trouble to bite the bullet and buy the VM software. Venturing just a tad OT here, but I feel obliged to share the good news Mark Wieder shared with me a few years ago: VirtualBox https://www.virtualbox.org/ Free as in both beer and freedom, in my experience it also outperforms Parallels rather dramatically in the time it takes to restore a session, and has pretty much all the modern features we've come to expect from such tools: - Your choice of single-window or interleaved modes - Wide range of hardware access and emulation options - Support for snapshots - Clipboard and shared folder integration - Very easy to use Thank you Mr. Wieder for turning me on that gem! -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Helping newcomers anticipate that standalones can't save to themselves
Thank you, Richard, for the URLs regarding JSON. Have you used any of them? Do you recommend one? As for LC-library to make working with CouchDB more convenient, it is a project of mine. I should have this all worked-out in the coming weeks. I will share it with y'all, once it's completed, polished, and documented. Meanwhile, if you discover such a lib (for CouchDB), please notify me. So much to do, so little time! ;-) On Friday, August 15, 2014 3:38:48 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Alain Farmer wrote: I am also interested in JSON, because this is the native format of JavaScript, Couch, and MANY other tools. It is essential for inter-operability. Btw, Couch is a relatively-new no-SQL database, much faster than any SQL, designed for massive distributed systems, specialized in replication synchronization. Couch's API is native HTTP : HEAD, GET, POST, PUT, DELETE. Meanwhile, back at the LiveCode ranch, it would indeed be nice to be able to handle JSON, load it as an array and/or a graph. Is it the case already ? With CouchDB's main API being HTTP-based, do you know if there's a library for LC to make working with it even more convenient? As for JSON, there are several libraries that convert LC arrays to JSON and back again: http://revonline2.runrev.com/stack/82/LibJson-1-0b https://github.com/luxlogica/easyjson https://github.com/montegoulding/mergJSON http://www.rozek.mobi/LiveCode/JSONlib/index_scr_en.html -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.com http://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Helping newcomers anticipate that standalones can't save to themselves
Alain Farmer wrote: Thank you, Richard, for the URLs regarding JSON. Have you used any of them? Do you recommend one? Unfortunately I'm useless to you there: the only service I've had to talk to that uses anything like that is for a very trivial datum in which a simple offset call does what I need. Most of my work these days is in systems in which both client and server are exclusively LiveCode, so it's hard to be both the convenience, compactness and efficiency of LC encoded arrays as a data package. In fact, after reading up on MongoDB's internals, it seems that LC arrays are very similar in many respects to BSON, just a bit more compact in some respects (no VINTs in LC, just UINT4s): http://bsonspec.org/ As for LC-library to make working with CouchDB more convenient, it is a project of mine. I should have this all worked-out in the coming weeks. I will share it with y'all, once it's completed, polished, and documented. Looking forward to it. I enjoyed the work you did with FreeGUI, and always admired your spirit of community supportiveness. Meanwhile, if you discover such a lib (for CouchDB), please notify me. Will do. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
