Please note – there may be a lag of up to a few minutes from 5PM for all the stats to update as we put through the last of the pay later pledges.
read moreThis is One Powerful Crowd
by Steven Crighton on July 27, 2014 20 commentsOver the last 13 months since being with LiveCode the strength and loyalty of this community has never failed to amaze me. We are a bigger & stronger community than we have ever been and that is very powerful. It means that all of us together can control the future of our product.
In 2013 we ran our first Crowdfunding campaign on Kickstarter and this is where we stood up and showed the world that the LiveCode community is here to make a difference. We are here to make a better coding experience and we are not stopping until we achieve that.
A few months ago Kevin Miller LiveCode CEO (my boss) approached me about running a crowd funding campaign to bring HTML5 Web Output into LiveCode. My first thought was not worry or fear, it was excitement. I was so impressed that we were making a decision to go big, we were not sitting back on our 2013 success, we were saying, well we ain’t done yet, so let’s make a better LiveCode and let’s do it now. My second thought came in the form of about a million questions and I want to try and take you through that journey now.
TidBITS – LiveCode Crowdfunding HTML5 Web App Deployment
by Jana Doughty on July 25, 2014 No commentsWe need your help: 6.7 and 7.0 Final DP’s released
by Ben Beaumont on July 22, 2014 14 commentsAfter months of hard work both from the LiveCode team and the community in testing we’re nearing the release candidate cycle for both 6.7 and 7.0. Today we release the final DP or “developer preview” of 6.7 and 7.0 containing more than 180 fixes.
LiveCode 6.7 contains many new features and refinements to the high DPI support:
- Cocoa – Latest Mac OS API’s making your apps a 1st class citizen on that platform
- coreText – Faster rendering of text on Mac OS
- webKit browser – Improved desktop web browser with two way Javascript communication
- Extended in-app purchasing – Support for Samsung and Kindle stores
- AVFoundation – New multimedia playback on Mac enabling appStore submission
- Effective points of graphics – A great community contribution from Mark Wieder
- Nine-way stretch for images – Making fluid layout skinned applications even easier
- 126 bug fixes
LiveCode 7.0 contains a completely restructured engine and will be the foundation of everything we do in 2014/2015
- Transparent Unicode support – Create apps in any language.
- New chunk expressions – Paragraph, sentence, trueword, codeunit, codepoint
- Engine refactor – New modern internals making development easier and external contributions simpler
- Linux GDK port – This is similar to the Cocoa port for Mac. Linux users will now enjoy better platform features
- 181 bug fixes
Developer previews / release candidates?
A developer preview (or “DP”) is a build of LiveCode that contains new features that we would like to offer to the community for testing and feedback.
A release candidate (or “RC”) is a build of LiveCode that contains new features that we propose are ready for release. During the release cycle the team focuses on testing, refinement and bug fixes. Bugs found are fixed and a new release candidate is built. Multiple RC’s are released until the build is deemed stable.
A stable release (or “GM”, short for “Golden Master”) is a build of LiveCode that is feature complete and at the time of release bug free.
How can you help?
We invite you to download and test your projects in both of these releases.
Testing is easy. Simply open your projects in LiveCode 6.7 and 7.0 and run through your normal testing procedure. You may have written automated tests for your product or work methodically through your app, testing each of its features. Either way, doing this will reveal any changes to the behaviour of LiveCode. Our aim when redeveloping both 6.7 and 7.0 was to make stacks run EXACTLY as they did in previous versions of LiveCode. For the most part, we have achieved this so 99% of stacks should run unchanged. If you notice any changes in behaviour or experience any instability please file a bug report at quality.runrev.com.
When will you go RC?
These are the last developer preview builds. The next builds will be release candidates which we hope to make available at the end of next week. Much will depend on feedback from you and whether we can resolve the issues reported over the weekend and through next week. We are still working on a multi-core rendering optimisation that will enable LiveCode to use all available CPU cores when rendering your stacks. It looks like it will offer some good performance improvements and will be released in the first RC builds.
Why not merge 6.7 and 7 into 1 release?
Some of you have asked why we don’t put 6.7 and 7.0 together into a single release, especially considering they are both coming out at the same time. Our primary motivation is you, our users. Many rely on our technology in your businesses and 6.7 provides a much smaller jump in changes upon which to deliver your products. The 7.0 developments have changed the way your stacks read in and write out out to disk as well as altering the performance profile of LiveCode. Certain operations in LiveCode are now slower while others are much faster. Text manipulation is at the heart of the LiveCode engine which now stores and processes strings as Unicode which is much more complex than the previous native format. Almost every command and function in LiveCode interacts with text meaning that many now perform at different speeds than they did before. Providing a 6.7 release enables those of you who need to tweak your apps for 7.0 the time to do so.
Where can I get these releases?
You can download installers at downloads.livecode.com or choose “check for updates” from the help menu in LiveCode.
Report it at quality.runrev.com. The better your report the more quickly our test team can reproduce and the easier it is for our developers to identify the problem in the source and fix it. A great bug report would contain:
1) A simple sample stack with a script that triggers the issue. The simpler, the better.
2) A step by step guide to causing the issue. E.g:
a) Open the attached sample stack
b) Click on the “start” button
c) RESULT: Causes LiveCode to misbehave is x,y and z ways
d) EXPECTED RESULT: LiveCode previously behaved like a,b and c
Where can I find out about the specifics in these releases?
We provide release notes with every build of LiveCode. These provide details of every feature, change and bug fix made in the release. You can find links to the release notes at downloads.livecode.com and from the help menu in LiveCode.
read moreNew Pledge Added, Newsletter Available
by Heather Laine on July 21, 2014 6 commentsIn our last newsletter we asked you to tell us if you wanted an additional combined pledge to get both the current Indy platforms and the HTML5 deployment when it becomes available. We were immediately flooded with requests for this pledge so we have added it for you. Pledge for the Combined Indy All Platform license to get 1 year of immediate Commercial access on all current supported platforms, and 1 year of HTML5 deployment when we have completed it. You can get it here, now. Thank you so much for all the feedback!Â
We have received a lot of questions about the campaign, so we pulled them all together into a newsletter article, which you can read here if you are interested. There is also a great article from some of our users describing what they expect to use HTML5 deployment for. I hope you enjoy reading it and find it inspirational. Let’s keep those pledges coming in!
read moreGetting Back up to Speed
by Ian Macphail on July 17, 2014 9 commentsRecently we’ve noticed a bit of sluggishness creeping into the LiveCode engine, particularly when it comes to graphics. Over the last few weeks I’ve been working with Michael to investigate and put into action some ways to get the engine back up to speed and get your apps whizzing again.
Looking into this problem, we’ve identified one of the big contributing factors as the introduction of support for high-density displays – where previously an app on the iPhone may have covered an area of 320×480 pixels, on a device with a retina display it now covers 640×960 pixels – that’s 4 times the number of pixels that need to be drawn when updating the screen! This is even more noticeable on mobile devices, where the processing power can’t match that of the desktop.
So what can we do to speed things up a bit? One option is to go multi-threaded. A thread is a block of code that can be made to run independently of the main program. By splitting a task up into multiple threads, different tasks can be made to run concurrently rather than one after the other. Most modern processors have multiple cores – that is multiple separate CPUs that are each capable of running a single thread all at the same time. We can take advantage of this by splitting up the job of redrawing the screen into several smaller tasks, i.e. by splitting up the area that needs redrawing and giving each smaller area to a separate thread. This promises to deliver a pretty big speed-up when redrawing.
One other option that I’ve been working on involves making sure we don’t do more work when drawing than we need to.
There are many ways to try and make computer programs work faster. You can try to find inefficiencies in your code that make things slower than they need to be – perhaps you have a loop in which the same value is computed repeatedly, in which case it may be more efficient to compute that value once and store it in a variable to be referenced later. Another strategy is to make better use of the resources available – the example being the use of multi-threading discussed above. However, if you know a particular operation is going to take a long time maybe you can find a way to avoid doing it altogether, or as little as you can manage.
In recent years we introduced a couple of new graphical features that allow you to add color gradients to graphic objects and graphic effects to everything. These features both require a lot of computation to draw, and as such they can be the slowest to draw when updating the screen. We spent quite a lot of time and effort on making these as fast as possible, but even then they can slow things down considerably when the area they cover is large.
So let’s say you have a card with a nice gradient as the background. You click a button that performs some operation then updates the contents of a field and maybe toggles some other buttons on or off. If this all happens as a single operation then each of those objects affected will have to be redrawn at the same time. Whenever a change happens to an object that requires it to be redrawn (changing the color of a graphic, or updating the contents of a field for example), its enclosing rectangle will be added to the redraw region.
A region is a graphical programming object that collects together multiple rectangles as a single area and allows several useful operations to be performed on that region. You can add or exclude rectangles from the region, or combine that region with another. This makes them pretty useful for defining the areas of a scene that we need to redraw.
Once we know what areas of the window need redrawing the engine will then tell the windowing system (the part of the operating system responsible for handling windows) that we want to redraw, after which the engine will receive a message back telling which areas of the window to update. This allows the OS to have areas of the window redrawn if for instance another window is passed over ours.
Now we need to draw to the window in the area given to us by the OS. In order to prevent flickering as different objects are drawn we use double-buffering. This is a technique where an offscreen image (the buffer) is created into which we draw, after which the complete image is then drawn to the window, so only the end result of the redraw operation is seen.
How then do we reduce the amount of redrawing that gets done? Well, previously the engine would confine the drawing area to a rectangle by setting the clipping rect of the graphics context that is used to draw to the buffer. The old graphics context would only allow the clipping area to be set to a rectangle, so if the area being redrawn was composed of smaller rectangles with lots of space between them, there was no way to prevent those unneeded areas between from also being drawn into. By using the new graphics context introduced by the graphical refactor, and updating it to accept a region as the clipping area, we can now ensure that only those areas that need updating are redrawn, with those areas in between getting skipped over.
Going back to our example, we can see that previously a much larger area (the rectangle encompassing all the affected controls) would have been redrawn, whereas now only the much smaller individual areas covering the affected controls will be drawn. For a stack with an expensive (in terms of time needed to draw) background this provides a significant saving in the time spent updating the window.
This was a pretty satisfying job for me – I got to update some more of the older code in the engine, replacing lots of platform-specific region code with a single region object that could be used on all platforms – and one that was successful in improving the experience of users of LiveCode developed applications.
read moreGeeky Gadgets – LiveCode HTML5 Web Delivery Crowd Funding Campaign Nears $80k (video)
by Jana Doughty on July 15, 2014 No comments20% Tipping Point Achieved!!
by Kevin Miller on July 15, 2014 No commentsToday something hugely exciting happened and you were all a part of it. We passed the 20% tipping point. Crowd funding statistics show that once a project gets past 20% it has an 80% chance of being successful. Cause for optimism? You bet. For complacency? No way. Our project is only done when it actually crosses the line. Lets keep the momentum going.
Our campaign has had some coverage on the web:
http://www.sdtimes.com/content/article.aspx?ArticleID=71449&page=1
http://www.marketwatch.co.uk/news/LiveCode.html
http://www.forall.ch/WordPress/2014/07/10/bring-html5-web-delivery-to-livecode/
http://livecloud.io/tag/crowdfunding/
We always need more coverage, so if you know of a website you think should be covering us, please do submit the story!
Our RunRevLive.14 Simulcast broadcast is now a part of the $99 Membership pledge. Watch the whole conference remotely as it happens, rewind and review it later. We have added a new $1999 lifetime upgrade commercial license reward tier. If you supported us before for a Lifetime license, make sure HTML5 gets funded and get yourself $500 worth of coupons every year for 5 years to spend in our store. We’re hugely grateful to all of you who have already made this pledge!
We’re working flat out here to bring you more. We’ll have a newsletter, new blog posts and more shortly. Let’s see if together we can get the total to $100,000 by the end of the weekend!
We need YOUR SUPPORT to keep this campaign on track for its target. If you have ideas for promoting it or suggestions as to what more we could be doing, please let us know!
read more
Recent Comments