Below is an exclusive screenshot of the LiveCode RTL edition for left handed users. As you can see we have flip reverse engineered the right handed version of the platform making it now 100% accessible to left handed users.
read moreAs I mentioned in my previous blog post, Unicode text is hard (which is one of the reasons it has taken such a monumental effort to get LiveCode 7.0 ready for release – it is now in public testing if you’d like to try it out). In order to make everything work transparently for the writers and users of LiveCode stacks, a lot has to go on behind the scenes. In this post and its follow-up, I hope to explain how some of these innards work. This first post is a bit technical but will lay the groundwork for some new Unicode text processing techniques.
The most important thing with Unicode is to understand what is meant by a character – different people have different definitions, some quite technical. Older computer software will often refer to 8-bit bytes as a character, a standard which LiveCode and its predecessors followed. Sometimes, "character" is used for the symbols defined by the Unicode standard (these are more properly termed "codepoints"). Neither of these is necessarily what a human reader would think of as a character, however.
Consider the letter "é" – that’s obviously a single character, right? Well, it depends on who you ask… Considered as 8-bit bytes, it could be anywhere between 1 and 8 "characters". Looking at it with Unicode-coloured glasses, it could be either 1 or 2 codepoints. However, in LiveCode 7, it is always a single character. If you were a Unicode geek like me, you’d call this LiveCode definition a "grapheme cluster".
Why do these different interpretations arise? If you’ll bear with me, I’ll take it apart piece-by-piece.
First comes the codepoints. The Unicode standard defines two types of representation for accented characters known as "composed" and "decomposed". Continuing with "é" as our example, Unicode would call this U+00E9 "LATIN SMALL LETTER E WITH ACCUTE" in its composed form. In its decomposed form, it would be a U+0065 "LATIN SMALL LETTER E" followed by U+0301 "COMBINING ACCUTE ACCENT". Basically, composed versus decomposed is the choice between accented characters being characters in their own right or instead being an un-accented character with an accent atop it. Conversion between these forms is called "normalisation" and will be discussed in my next post.
Next comes the variable number of bytes that are used to store these codepoints – this comes down to how these codepoints are encoded. Sometimes, old 8-bit encodings have a single byte to represent a particular composed character. Unfortunately, these encodings can only represent 256 different characters so Unicode encodings are used instead. The particular encoding used within LiveCode is UTF-16 (but this is internal to the engine and isn’t visible to LiveCode scripts).
The UTF-16 encoding uses 16-bit values to store codepoints, termed "code units". This extra term is needed because although many languages have all of their symbols representable using a single code unit, a number (including Chinese) need two code units per codepoint for certain characters, due to the large number of symbols within the language. Because of this, a codepoint can be either 2 or 4 bytes in length when encoded with UTF-16.
Other common text encodings are:
As you can see, there is a fair bit of complexity behind the transparent Unicode support in LiveCode 7. In my next post, I’ll show you how you can take advantage of knowing how it all fits together.
read moreWe are pleased to announce the preview release of LiveCode 6.7.0 DP1.
For those of you that don’t know, LiveCode releases come in different stages.
DP – developer preview (feature incomplete likely to be unstable)
RC – release candidate ( feature complete, likely to be quite stable but is not considered the final stable release)
GM – gold master ( feature complete stable release)
The primary focus of this release is cocoa support. This required us to re-port LiveCode to the newer Mac platform API’s (cocoa). As a result, there may be some instabilities on Mac OS. Once again, thanks to those who helped with alpha testing to iron out the major bugs. 6.7 has now passed all automated tests and a first pass community test. We are aware of a sporadic crash related to audio which we’ve been unable to replicate or trace.
Release Contents
* Our in-app purchasing implementation for the Amazon AppStore is unfortunately restricted to commercial license holders only. This is due to the Amazon PML license being incompatible with the GPL. If you wish to use the Amazon in-app purchasing features of LiveCode you will need to be a valid commercial licence holder.
For full details of features and fixes please see the release notes: http://downloads.livecode.com/livecode/6_7_0/LiveCodeNotes-6_7_0_dp_1.pdf
Known Issues
Testing
As always we appreciate very much all those who help us refine these early releases.
Reporting Bugs
If you encounter an issue with this release please submit a bug report to our quality centre: http://quality.runrev.com/enter_bug.cgi
Get the release
To upgrade to this release please select "check for updates" from the help menu in LiveCode or download the installers directly at: http://downloads.livecode.com/livecode/
Resources
For lessons related to the new in-app purchasing api please see: http://lessons.runrev.com/m/19606
THERE ARE INSTABILITIES IN THIS PREVIEW RELEASE so please take care to use backups of your stacks when testing.
read moreThis release brings automatic scaling and handling of Retina screens to the desktop platforms, in line with the existing iOS and Android support. Also in this release open SSL and encryption support have been added for the mobile platforms. LiveCode continues to increase the feature parity available on all six supported platforms it offers.
We recognize that whilst the mobile platforms are continuing to grow and mature in terms of apps and development, the desktop platforms are vitally important to developers and end users alike. We are proud to offer seamless support for a huge variety of screen sizes, shapes and densities with LiveCode 6.6. Now you can write the same single line of code to handle scaling for your app on the smallest Android device and the largest Mac Retina screens.
A new assert command has been added to help people who wish to write tests. It was primarily written to support in-house testing of LiveCode but has been documented in the release notes so LiveCode developers can also make use of it with their projects.
High DPI support on windows and OSX has been added meaning LiveCode applications will now run at the native screen resolution on computers with high density screens. For example, the MacBook Pro now comes with a ‘retina’ screen which has 4x the number of pixels than a standard laptop screen. The extra pixels are there to make the apps on screen crisper, rather than provide more screen real estate. By default, the OS up scales applications implemented without High DPI support to the high density screens, resulting in some pixilation. LiveCode 6.6 now creates apps in the new format allowing the OS to render them at the true screen density. The result, your app looks beautiful!
LiveCode CTO Mark Waddingham talks about the High DPI in his blog post titled – Hi-speed HiDPI
When running a stack in fullscreen mode you can tell LiveCode how you want your app to be scaled. In LiveCode 6.5 we added a number of scaling options and in 6.6 we added an additional one. ShowAll scales the stack preserving aspect ratio so all content within the stack rect is visible. Portions of the stack outside the stack rect will be visible if the scaled stack does not fit the screen exactly.
The desktop version of LibURL has been updated to support fetching HTTPS URLs through a proxy server. Anyone writing an app that was deployed to a network secured by proxy could not access internet based URLs. LiveCode now supports auto-detection of proxy server settings so that developer apps will automatically tunnel outside of a network with zero configuration.
Due to a degrade in the image resizing quality in 6.5, the image filtering algorithms have been updated for 6.6.
For LiveCode versions prior to 6.5, the image filtering algorithms were not universal across all platforms. "Good" resize quality used bilinear filtering and "best" used bicubic filtering for all platforms. However, "normal" differed. On Mac, box filtering was used. All other platforms applied no filtering.
For LiveCode versions prior to 6.5, all resize operations were cached (i.e. moving a resized image around did not cause the resize to be recalculated).
For LiveCode 6.5, the image filtering was united across all platforms, with no filtering being applied in "normal" mode, bilinear filtering being used in "good" mode and bicubic filtering being used in "best" mode.
For LiveCode 6.5, only "best" resize operations were cached (the acceleratedRendering mode should be used for caching in other modes). All others were calculated on the fly.
The bilinear filter used in 6.5 was of poorer quality when compared to pre 6.5. Additionally, the "normal" mode on Mac was poorer (due to the loss of the box filter). We’ve addressed this in LiveCode 6.6 by improving the image filtering algorithms across all platforms. "Normal" and "good" mode now use updated algorithms. "Best" mode remains as before.
It should be noted that the improvements to the filters used may cause a slight drop in performance. The final image filters and resize modes used has not been finalized and is open to user input.
Support has been added for iOS 7.1. For OS 10.8 and 10.9, LiveCode now uses the iOS 7.1 SDK to produce device builds. As such, OS 10.8 and 10.9 users must have the iOS 7.1 SDK installed (which comes with Xcode 5.1) and configured in their mobile preferences in order to produce iOS device builds.
Open SSL & encryption support has been added to the iOS and Android engines (using LibOpenSSL version 1.0.1e). This allows developers to use the encrypt and decrypt commands on the mobile platforms in exactly the same way they would on desktop. In order to include the SSL and encryption libraries, developers must tick the "SSL & Encryption" checkbox in the iOS/Android pane of the standalone builder.
The version of SQLite has been updated to 3.8.3. We have also cleaned up the way you connect to the database making it simpler, as well as improving binary data support.
Binary data can now be placed into SQLite databases verbatim (without the encoding that used to occur) – this means databases can be made to contain binary data which is compatible with other applications. To utilize this functionality, the ‘binary’ option must be passed to the revOpenDatabase() call when creating the database connection (see below).
The new scaleFactor stack property allows you to set a custom scale factor for a stack. If you are working on a stack that is larger than your screen, you can ’zoom out’ by reducing the stack size via the scaleFactor property. The stack appears smaller and all assets are scaled, however, the stack still reports to be its native size.
Hashbangs ‘#!’ is now recognized by LiveCode Server – this brings the LC Server engine more in line with expected behaviors in the Unix/server scripting world.
55 bugs have been fixed in this release making it more stable than previous releases.
Your LiveCode install should prompt you to download this latest release. Alternatively you can download the latest release from the LiveCode Download area
read moreThis release brings automatic scaling and handling of Retina screens to the desktop platforms, in line with the existing iOS and Android support. Also in this release open SSL and encryption support have been added for the mobile platforms. LiveCode continues to increase the feature parity available on all six supported platforms it offers.
We recognize that whilst the mobile platforms are continuing to grow and mature in terms of apps and development, the desktop platforms are vitally important to developers and end users alike. We are proud to offer seamless support for a huge variety of screen sizes, shapes and densities with LiveCode 6.6. Now you can write the same single line of code to handle scaling for your app on the smallest Android device and the largest Mac Retina screens.
A new assert command has been added to help people who wish to write tests. It was primarily written to support in-house testing of LiveCode but has been documented in the release notes so LiveCode developers can also make use of it with their projects.
High DPI support on windows and OSX has been added meaning LiveCode applications will now run at the native screen resolution on computers with high density screens. For example, the MacBook Pro now comes with a ‘retina’ screen which has 4x the number of pixels than a standard laptop screen. The extra pixels are there to make the apps on screen crisper, rather than provide more screen real estate. By default, the OS up scales applications implemented without High DPI support to the high density screens, resulting in some pixilation. LiveCode 6.6 now creates apps in the new format allowing the OS to render them at the true screen density. The result, your app looks beautiful!
LiveCode CTO Mark Waddingham talks about the High DPI in his blog post titled – Hi-speed HiDPI
When running a stack in fullscreen mode you can tell LiveCode how you want your app to be scaled. In LiveCode 6.5 we added a number of scaling options and in 6.6 we added an additional one. ShowAll scales the stack preserving aspect ratio so all content within the stack rect is visible. Portions of the stack outside the stack rect will be visible if the scaled stack does not fit the screen exactly.
The desktop version of LibURL has been updated to support fetching HTTPS URLs through a proxy server. Anyone writing an app that was deployed to a network secured by proxy could not access internet based URLs. LiveCode now supports auto-detection of proxy server settings so that developer apps will automatically tunnel outside of a network with zero configuration.
Due to a degrade in the image resizing quality in 6.5, the image filtering algorithms have been updated for 6.6.
For LiveCode versions prior to 6.5, the image filtering algorithms were not universal across all platforms. “Good” resize quality used bilinear filtering and “best” used bicubic filtering for all platforms. However, “normal” differed. On Mac, box filtering was used. All other platforms applied no filtering.
For LiveCode versions prior to 6.5, all resize operations were cached (i.e. moving a resized image around did not cause the resize to be recalculated).
For LiveCode 6.5, the image filtering was united across all platforms, with no filtering being applied in “normal” mode, bilinear filtering being used in “good” mode and bicubic filtering being used in “best” mode.
For LiveCode 6.5, only “best” resize operations were cached (the acceleratedRendering mode should be used for caching in other modes). All others were calculated on the fly.
The bilinear filter used in 6.5 was of poorer quality when compared to pre 6.5. Additionally, the “normal” mode on Mac was poorer (due to the loss of the box filter). We’ve addressed this in LiveCode 6.6 by improving the image filtering algorithms across all platforms. “Normal” and “good” mode now use updated algorithms. “Best” mode remains as before.
It should be noted that the improvements to the filters used may cause a slight drop in performance. The final image filters and resize modes used has not been finalized and is open to user input.
Support has been added for iOS 7.1. For OS 10.8 and 10.9, LiveCode now uses the iOS 7.1 SDK to produce device builds. As such, OS 10.8 and 10.9 users must have the iOS 7.1 SDK installed (which comes with Xcode 5.1) and configured in their mobile preferences in order to produce iOS device builds.
Open SSL & encryption support has been added to the iOS and Android engines (using LibOpenSSL version 1.0.1e). This allows developers to use the encrypt and decrypt commands on the mobile platforms in exactly the same way they would on desktop. In order to include the SSL and encryption libraries, developers must tick the “SSL & Encryption” checkbox in the iOS/Android pane of the standalone builder.
The version of SQLite has been updated to 3.8.3. We have also cleaned up the way you connect to the database making it simpler, as well as improving binary data support.
Binary data can now be placed into SQLite databases verbatim (without the encoding that used to occur) – this means databases can be made to contain binary data which is compatible with other applications. To utilize this functionality, the ‘binary’ option must be passed to the revOpenDatabase() call when creating the database connection (see below).
The new scaleFactor stack property allows you to set a custom scale factor for a stack. If you are working on a stack that is larger than your screen, you can ’zoom out’ by reducing the stack size via the scaleFactor property. The stack appears smaller and all assets are scaled, however, the stack still reports to be its native size.
Hashbangs ‘#!’ is now recognized by LiveCode Server – this brings the LC Server engine more in line with expected behaviors in the Unix/server scripting world.
55 bugs have been fixed in this release making it more stable than previous releases.
Your LiveCode install should prompt you to download this latest release. Alternatively you can download the latest release from the LiveCode Download area.
Find more information on LiveCode 6.6 here.
read moreIt is great teaching children how to program and their motivation can be particularly high if the turnaround time is short and the app has a practical benefit to them.
My daughter has a passion for all stuff technical and especially loves mathematics, and of course she is not new to LiveCode. When she was eight I introduced her to the idea of writing a calculator and it did not take much arm twisting to get the project going.
We started by creating the UI and dragged a field onto a card for the display and buttons for the input. We then added symbols to the buttons that you would normally expect to see on a calculator. UI done, and this was clearly the most fun part for my daughter.
Then came the code that we placed in the card script. If you have experience with other programming languages, then implementing a generic evaluation function for equations can be somewhat beyond the level of a simple childrens’ app. Anyway LiveCode has this covered and allows you to implement a basic calculator algorithm in less than 10 lines of code, and that includes the handler name:
on mouseUp
if the short name of target is "=" then
do "do" && quote & "put" && field 1 && "into field 1" & quote
else if the short name of target is "C" then
put empty into field 1
else if word 1 of the name of target is "button" and (char -1 of field 1 is a number or char -1 of field 1 is not the short name of target) then
put the short name of target after field 1
end if
end mouseUp
This code consists of an "if statement" in which three possible display altering lines of code can be executed. The first part of the "if condition"
tests if the "=" button was pressed, with the "do …" line performing all of the evaluation magic and placing the result into the display field. Take a closer look at that line and check out how much it actually does.
The next part of the "if statement" tests if the "C" button was pressed and then allows the code to be executed that clears the content of the display field.
The last part of the if condition tests if the button pressed is valid for display in the display field. If it is, the value is placed at the end of the content that is already displayed in the display field.
Calculator done, we decided to skipped some of the "do" details and enjoyed the fact that it worked.
Now this is a very simple implementation of a calculator and certainly keeps attention focused while you put the app together. There are obvious shortcomings that would merit further development, for example some graceful exception handling if the function evaluation should fail, and of course calculators can come with loads more buttons than the ones shown here. Try adding some other features and see what else you can calculate with this app.
If you have similar experiences or suggestions for cool kids’ apps, then I would love to hear from you and see what great experiences you have had.
read moreThe price of a ready made curry at the local supermarket has gone down. This is a good thing. The portion size of a ready made curry at the local supermarket has also gone down. Out of proportion to the price drop. This is a bad thing. And it’s what I’m attributing the yelps of anguish to that can be regularly heard around the RunRev office at the moment.
Or it could be the pains of integration. You see, several long running projects are now coming together. And this means integrating several months of hard work into a single LiveCode installer. Which is far, far harder than you can ever imagine. The build process is almost entirely automated. But due to the complexity of the process and the number of platforms to support, there are so many points at which it can fail. And as soon as you solve one problem, several others appear to take its place.
It’s these final steps that developers find so frustrating. After months of implementing new features, you think the all the hard work is done. But in reality, it’s only just begun. It’s almost enough to force developers to get up and microwave their own curries.
We have an automated test system that we run on all new builds. This ensures that all releases we put out are of the highest quality. This is a good thing. The test system has a habit of spotting critical bugs moments before we’re about to push the release button. This is a bad thing. Especially if it’s last thing on a Friday. Often, the fix itself is trivial. But the dreaded rebuild that follows is usually not.
Dependencies are supposed to make the build process smoother. But it seems they fail when you most need them: Fraser once told me that if you so much as look at libSkia funny, it will decide a full rebuild is needed. I believe him. We have a dog in the office named Pancake and she’s always looking at me funny. I can only assume she gives the same treatment to libSkia. I’m not laying blame though. I think that’s just what her face looks like.
Within the next few months several new and exciting versions of LiveCode will be released. This is a good thing. For the next few months, us LiveCode developers will be spending all our time fixing bugs and refining features. Well, this is a good thing, for you at least…
read moreThere are a lot of things to tell you about LiveCode 7.0, and of course we will be writing about many of them in upcoming blog posts. For this blog I’m going to tell you bit about some of the new chunk types that have been introduced. There are 7 new chunk types if you count the new synonym, which I do if only to allow for the chiastic blog title – byte, codeunit, codepoint, trueWord, segment, sentence and paragraph.
Arguably the most important new chunk types are the sentence and trueWord chunks. These new chunk types make analysing text much easier than it was previously. Suppose you want to know how the first sentence of Mary Shelley’s Frankenstein compares to the rest of the text, in terms of the number of words it contains (I’m sure you do). Well you can find out if it is smaller than average with ease:
But you needn’t be restricted to English texts, control names or indeed variable names in 7.0. Perhaps you’re interested in the frequencies of different words in the original Russian of Dostoevsky’s Crime and Punishment (I’ve no doubt that you are). Simply repeat over the trueWords of your “Преступление и наказание” field, count, and process.
The most important feature of the new trueWord and sentence chunks is that they draw on a large base of rules about sentence and word boundaries provided by the ICU library. This means in particular that word breaks are identified in places that would be impossible to detect in older versions of LiveCode. Suppose you’ve got a sentence written in Chinese which you want to divide into its constituent words (I’m absolutely certain you have). In this example I’m just using “Hello World.”
The segment chunk, a synonym of the old word chunk, looks for space characters as delimiters, whereas the trueWord chunk uses the ICU data to split the string correctly.
Note that in addition to all the variables, LiveCode 7 is perfectly happy to have a handler named 处理 (“process” – although I don’t claim it is conjugated correctly for this context)! I also exported the snapshot of that stack to a file named “快照.png” from the message box because… well, just because.
Also added is the paragraph chunk. It is very similar to the existing line chunk except it can also be delimited by the Unicode paragraph separator character. This means that it is more useful for processing text which is or will be displayed in a field – field text breaks are precisely the delimiters of the paragraph chunk.
Finally there are the codepoint and codeunit chunks. Well, there’s also the byte chunk, but that should only be used for binary data. For greater detail on these chunks, you should consult the release notes for LiveCode 7.0., but I thought I’d mention a potential application that occurred to me. Imagine, if you will, that you want to make sure Georges Perec and his translators had done a good job with their constrained writing (of course you do). Well the codepoint chunk (with a bit of help from normalizeText) can help you out!
Now here’s a challenge. What’s the longest chunk expression you can find a genuine use for? Put codeunit a of codepoint b of char c of token d of trueWord e of segment f of item g of sentence h of paragraph i of line j… (of field k of group l…)
To upgrade to this release please download the installers directly at: http://downloads.livecode.com/livecode/
To view the release notes please visit: http://downloads.livecode.com/livecode/7_0_0/LiveCodeNotes-7_0_0_dp_1.pdf
read more
Recent Comments