LiveCode Community is an Open Source project. This means that if you know C++, you can get right into the innards and add your own features, fixes, and enhancements. Your new features (after a careful screening process) get incorporated into LiveCode itself, making it better for everybody. If you feel that working with C++ just isn’t for you and you’ve come across a bug (nasty little critters!), we still care. We don’t expect you to do it all yourself. You can report bugs and request features in the traditional way. Find out more about how to contribute below.

How to Contribute
Spreading the Word
Helping Other Users
Quality Control
Creating an Account
Helping to Reproduce Bugs
Engine Development
Prerequisites
New to GitHub
Installing and using GitHub
Forking the LiveCode Repository
Compiling LiveCode
Communication
Contributors Agreement
The Patch Process
Types of Patches
Bug Fix Patches
Feature Patches
Architecture Patches
Regression Patches
Patch Acceptance
All Patches
Bug Fix Patches
Feature Patches
Architecture Patches
Regression Patches
Patch Guidelines
Appropriate Features
Responsibilities of RunRev Ltd
Things to Remember
Patch Processes
Bug Fixing Process (How do I fix a bug)
Documenting Bug Fixes
Bug Fix Questions and Answers
Regression Fixing Process (how do I fix a bug that was caused by one of my patches)
Adding a Feature
Patch Submission and Review
Coding Standard
Suggested Projects
Working on the Existing Roadmap
IDE Development
Contributions
Writing Documentation
Dictionary Entry Guidelines

The first version of LiveCode Open Source was released on Tuesday 9th April 2013.
This document is for anyone wishing to contribute to the success of LiveCode, whether by spreading the word, updating docs or helping with the development of the product itself. We warmly welcome contributions of all sorts.
This will be a living document which will evolve over the coming months. If you want to contribute and the answers aren’t here, or have a suggestion to make, please do drop us an email at quality@runrev.com.

How to Contribute

Spreading the Word

There are many ways you help the LiveCode OSS cause, regardless if you do or do not want to contribute to the code. The easiest way is by sharing LiveCode with others: recommend LiveCode to people and show them how to use it. Tell people why you use LiveCode. Share the joy of creating apps. As the LiveCode community grows, so does its influence and the more accepted LiveCode will become! You can spread the word by:

1. Evangelizing to your friends and family. Show them what you've made and encourage them to try it for themselves.
2. Blog about what you use LiveCode for.
3. Submit your story to us at support@runrev.com so we can share it.
4. Share information about your app on a community site, such as 1001 Things to do with LiveCode http://livecode1001.blogspot.co.uk/.
5. Send us a newsletter article for revUp editor@runrev.com.
6. Give a talk at your local school about the benefits of teaching programming with LiveCode.
7. Is there a user group in your area? If not, you might want to set one up. You can advertise your group on our forums http://forums.runrev.com/viewforum.php?f=30, or organize your own one (e.g. using Meetup http://www.meetup.com/ ).

Helping Other Users

You can make a big contribution to LiveCode by helping others get into the platform. One of the primary reasons new users come and stay with the platform is because of our active community. As the development community grows, we need more people to share that same warm welcome and be helpful, as was evident in the past.
You can do this by actively participating in the following portals:

		LiveCode Forums - All forms of discussion
		One of the most active areas of the forums is our beginners area. If you are keen to help new users as they learn LiveCode this is a great place to contribute. It is often quoted by new users as the primary reason they were successful with their projects.
		Beginner specific forum
		General forums
		LiveCode Staff Presence: Customer support team
		Uselist - All forms of discussion
		The use list is currently the most active discussion lists made up of beginners right through to experienced developers. This is a great place to join discussions and keep up with the most active community members. http://lists.runrev.com/mailman/listinfo/use-livecode.
		LiveCode Staff Presence: Customer support team
		Stack Overflow - Technical questions
		If you enjoy solving technical problems or helping people by writing short code snippets, then we recommend getting involved in the stack overflow community. Stack overflow is where we recommend asking intermediate and advanced questions. http://stackoverflow.com/questions/tagged/livecode.
		Asking good questions here is also a great way to support LiveCode. StackOverflow has become the primary portal for answers to questions relating to the majority of programming languages and is very well indexed by search engines.
		LiveCode Staff Presence: Development team members

Quality Control

You can help us improve the quality of LiveCode by getting involved in our bug management process. In particular, there is ample opportunity to help reproduce reported bugs and get involved in fixing bugs in the source code.
The Quality Control Center is open to everyone. You can report bugs, request that bugs are assigned to you and watch the progress of bugs that are being addressed. A helpful search bar is provided at the bottom of your Quality Control Center screen. This gives you instant access to bugs you raised, bugs that were assigned to you, bugs that require investigation and bugs that are ready to go into the next release.

Creating an Account

You can create your own Quality Control Center account by following this link:
Create an account here: http://quality.runrev.com/
Once you have set up an account, you can continue to use this link to access the Quality Control Center in the future.

Helping to Reproduce Bugs

We do not find all bugs during testing, and even after bugs have been reported, it is not always possible for us to replicate the issues. In these cases we request further information from the person reporting the bug, usually to provide us with a recipe that allows us to reliably replicate the issue. You can also help us reproduce these bugs by providing recipes for the problems reported.
These bugs can be accessed from your “Bugs Pending Follow Up” tab. The instructions on providing recipes is directly available from the Quality Control Center: http://quality.runrev.com/page.cgi?id=bug-writing.html

Engine Development

Prerequisites

RunRev Ltd uses GitHub to host the source files that make up LiveCode. This is where all the interaction with the LiveCode source files takes place. If you want to engage in making changes to LiveCode, you will need a GitHub account and to understand how to interact with GitHub. If you are only interested in obtaining an open source copy of the LiveCode files, then you can download the zipped bundle from GitHub without having to register with GitHub.

New to GitHub

If you are new to GitHub and you don’t know where to start then you can run through a short interactive tutorial that teaches you how to interact with GitHub. You can access the tutorial here: http://try.github.com

Installing and using GitHub

If you are looking for information on installing and using GitHub, then have a look at: https://help.github.com/
This provides answers to a number of common questions and gives you vital information about setting up GitHub and forking a repository.

Forking the LiveCode Repository

Forking LiveCode so you can work on it is a two stage process:
First you have to create a fork of a LiveCode repository. This fork resides within GitHub.
The second step is to create a clone of the fork you created. This copies the LiveCode source files onto your machine. You are then set up to modify the files before they are ready to be tested and pushed back into the product.
You can create a fork of a LiveCode repository by navigating to the LiveCode repository after logging into GitHub and selecting the Fork button. The direct link to the LiveCode repository in GitHub is: https://github.com/RunRev/LiveCode
You can then create a clone of your fork of the main LiveCode repository with the following GitHub command:

$ git clone --recursive https://github.com/<username>/LiveCode.git
$ cd LiveCode

Compiling LiveCode

Coming soon

Communication

If you are working on the LiveCode engine, then we recommend joining the Engine Contributors Forum.

		Engine Contributors Forum - All forms of discussion
		This forum is the place to discuss your ideas with other engine contributors. http://forums.runrev.com/viewforum.php?f=66
		We recommend that all active contributors subscribe to this forum. This is also the primary place for interacting directly with the LiveCode development team.
		a) If you have decided to commit to a specific project we recommend sharing your plans and suggested approach on this forum. It will enable us to feedback at the earliest stage and maximise the chance the patch will be accepted once submitted.
		b) You can also post here If you are actively working on a project and would like to discuss issues with the RunRev team or other active contributors.

Contributors Agreement

Users wishing to contribute code are required to sign a contributors agreement. This can be found here: http://livecode.com/store/account/contributor-agreement-signup

The Patch Process

Patching is the process by which you can make changes to the LiveCode source repository on GitHub.
This section describes the reasons for which it is possible to make changes to LiveCode and what is involved in making these changes.
The content of this section assumes that you understand how to use GitHub and are familiar with writing code in C/C++.

Types of Patches

There are four patch types that allow you to make changes to LiveCode. These are patches for bug fixes, features, architecture and regression. We define the patches as follows:

Bug Fix Patches

A bug fix patch corrects an error in the way LiveCode works, with a recipe or a set of circumstances normally allowing the bug to be replicated. Consensus will have determined if a particular behavior is indeed a bug. A patch that fixes a bug must only correct the bug and not change any other behavior of LiveCode or add extra functionality. A bug fix patch is always made against the master branch and tracks the master branch.

Feature Patches

A feature patch adds new functionality to LiveCode and may fix existing bugs at the same time. Feature patches should normally only add to existing functionality and not change the existing behavior of LiveCode. There are some circumstances where changes to the existing behavior of LiveCode is possible but the benefits should significantly outweigh the disadvantages. A feature patch is always made against the development branch and tracks the development branch.

Architecture Patches

An architecture patch is one or a collection of changes that improve the implementation rather than fixing bugs or add new features. An architecture patch is always made against the development branch.

Regression Patches

A regression patch is a change that fixes an issue that was introduced by other patches on the maintenance or development branches. A regression patch is always made against the appropriate branch.

Patch Acceptance

Once you have implemented changes that are to be applied to LiveCode in form of a patch, you need to consider if that patch matches a set of criteria that allows us to merge the patch into LiveCode. This ensures that we maintain a degree of consistency throughout the way LiveCode evolves.
The following criteria are used to determine whether a patch can be accepted and if it can be applied to the relevant branch.

All Patches

Certain requirements apply to all patches. These are as follows:

1. Patches must only contain code to which a copyright grant can be provided to RunRev Ltd (see contributor agreement).
2. Patches must not rely on third-party code or libraries unless prior agreement is in place with RunRev Ltd and there is significant and valid reason to include third-party code or libraries.
3. The patch must be applied to the HEAD of the appropriate branch at the point the patch is to be integrated by RunRev Ltd. Appropriate branches are:
   • Bug fix - master
   • Feature - development
   • Regression - maintenance or development

Bug Fix Patches

1. The patch must fix the bug specified.
2. The patch must fix the bug in an appropriate way.
3. The patch must fix the bug on all platforms it is appropriate to.
4. The patch must not (as far as is possible to determine) cause any regression bugs.
5. The patch should fix only a single bug, or a collection of highly-related bugs.

Feature Patches

1. The patch must implement a complete and stable feature.
2. The patch must only add and not change existing functionality unless previously agreed with RunRev Ltd. Changes in functionality must be done carefully and at appropriate points.
3. The patch must not rely on third-party libraries unless previously agreed with RunRev Ltd.
4. The patch must not add any syntax that has not previously been sanctioned by RunRev Ltd .This ensures there is a central decision making point that oversees language consistency and reduces ambiguity.
5. The patch must implement a feature wisely and with relevance to future development.
6. The feature implemented by the patch must be appropriate and maintainable by RunRev Ltd.

Architecture Patches

1. These should only be undertaken after significant and detailed discussions with engineers at RunRev Ltd resulting in agreement as to the work that is to be done.

Regression Patches

1. The patch must fix a recognised and reproduced regression bug on either the development or maintenance branch.
2. The patch must be limited in scope. Extensive regression patches indicate a flaw in one or more bug fix or feature patches. In such a case it may be more appropriate to pull one or more previous patches for re-integration.

Patch Guidelines

Appropriate Features

1. Ask on the contrib list before attempting to implement any feature.
2. LiveCode is a dual licensed project and RunRev Ltd is committed to maintaining all code in the GitHub repository. This commitment means that, we only accept code that we can maintain. For example, code that requires highly specialized knowledge is something we can probably not accept.
3. Features must be generally useful to a suitably large subset of users. Specialized features for highly specific use-cases cannot be accepted. We will in time provide a rich extensions API which will be more appropriate for these.
4. Features must only add to and not change the existing functionality of LiveCode, unless the benefits significantly outweigh the disadvantages. There must be a prior agreement with RunRev Ltd; and a logical and clear argument must be established if the functionality is to be changed.
5. Features must be orthogonal to the existing feature set and not overlap significantly with other existing features. If significant overlap exists, then this suggests that there is common abstraction lying underneath which should be the focus of the feature.
6. If the feature does not meet the requirements of the previous points and you still require the functionality, then it is possible that the feature can be added in form of a loadable library. You can ask us about how hooks could be added to the engine to enable the feature to be plugged in. In this scenario, only the code that adds the hook to the engine is needed as a patch and not the whole feature.

Responsibilities of RunRev Ltd

1. RunRev Ltd is responsible for managing the GitHub repository and branching model.
2. RunRev Ltd is responsible for providing ongoing support to commercial customers and to maintain any and all accepted patches.
3. RunRev Ltd is responsible for maintaining a balance between preserving backwards compatibility and evolving the platform.
4. RunRev Ltd is responsible to make decisions on patch acceptance based on what we perceive to be in the best interest of all users of the product.

Things to Remember

1. We are community oriented and are very happy to hear from you. Our engineers have many man-decades worth of experience, working with the engine source-code and all the platforms it supports. We are here to help and share that knowledge with you.
2. The existing engine architecture restricts the features you could contribute to the engine at the moment. Refactoring work on the engine is currently in progress and will result in a modularized engine will allow you to widely contribute to the functionality of the engine.
3. The user base of LiveCode is very diverse with a range of people at different skill levels who use LiveCode in many wonderful ways. When making changes to LiveCode it is important to keep this in mind and ensure we can continue providing and improving the diverse development environment that everyone has become used to.

Patch Processes

Bug Fixing Process (How do I fix a bug)

1. Get the bug assigned by emailing quality@runrev.com with the bug number.
2. Get a fork of the LiveCode repository.
3. Work on your bug fix on the master branch, making sure you track updates to that branch.
4. When the fix is complete, and it conforms to the patch acceptance rules outlined above for bug-fixes, document the fix (see below) and submit a pull-request for the patch.
5. Interact with the pull-request discussion as required to ensure your patch is accepted. Bug-fix patches are only applied at specific points in the maintenance cycle.
6. If the patch is accepted then the RunRev Ltd team takes on the responsibility of integration.
7. If the patch is not accepted, the RunRev Ltd team will explain why the patch was rejected, allowing you then make any necessary changes and submit a subsequent pull-request at a later date.
8. If your bug-fix cause regressions and/or integration problems, then it may get pulled from the particular cycle. The best way to avoid having your patches pulled from a cycle is by helping resolve any issues it may cause. RunRev Ltd has only limited resources and has to prioritise as is appropriate.
9. If your patch is accepted, the status of the bug report is changed to 'awaiting_build'.
10. Once the release is finalized, the status of your bug is changed to 'resolved' and your assignment is removed.

For full details on how RunRev Ltd process bugs through the quality control center please refer to the following document:
http://quality.runrev.com/page.cgi?id=bug-submission.html

Documenting Bug Fixes

Each bug fix should be supplemented by a description of the bug fixed. The first line in this file must be a one-line description of the bug prefixed by a hash symbol (# <description of bug>).
If you wish to give more specific information about the bug fix and any associated changes that were needed, this file can be extended with Markdown. The following elements are supported:

• Headers (# for <h1>, ## for <h2> etc.)
• Italic text (*Italic text*)
• Bold text (**Bold text**)
• Links ([<Link text>](Link URL))
• Images ()
• Indented text (begin lines with tab characters)
• Lists, either ordered:

 1. <item>
2. <item>
1. <subitem>

or unordered:

 * <item>
* <item>
* <subitem>

• Code (`Some code`)

Tables are also supported. The following syntax:

| Heading 1 | Heading 2 | ... |
---------------------------------
| Entry | Entry | ... |
| ... | ... | ... |

produces

	Heading 1	Heading 2	...
	Entry	Entry	...
	...	...	...

Bug Fix Questions and Answers

Q: What is the software scope of a bug?
A: In the context of fixing an issue, the scope of a bug can be defined as a self contained region of software that should normally be restricted to a single file and code path. Some fixes do require modification multiple files and can impact multiple code paths, although the modification to each file would be expected to very small.

Q: How can I have a bug assigned to myself?
A: If a bug has been confirmed with the status NEW, you can e-mail quality@runrev.com and request to be assigned to that particular bug.

Q: Does an assigned bug stay with me until I have completed it?
A: Generally speaking, yes, but in some cases RunRev may decide to implement the fix without warning or notification if absolutely necessary (e.g. in response to an urgent request from a commercial customer). In this case your assignment would change to someone else. You would receive an e-mail from the Quality Control Center, informing you that the bug had been reassigned. At this point it is important to remember that this would and should not reflect negatively in any way on your contribution to the bug report. This action would be taken purely as a result of bug prioritisation.

Q: What can I do if I can fix a bug that is assigned to someone else?
A: If you feel that you can address a bug that is assigned to someone else, then you could either suggest what changes to make to the bug or ask the assignee for permission to have the bug assigned to you. This communication should take place directly on the bug report. If the assignee is happy to transfer the bug report to you, then the Quality Control Center administrator can reassign the bug report for you.

Q: What do I do if I feel that I can no longer fix the bug?
A: That is not a problem. You just have to e-mail quality@runrev.com with the request to be taken off the bug. The bug will then either be assigned to someone else or be reverted to status NEW.

Q: What should I do if I feel that I can fix a bug that is still UNCONFIRMED?
A: If a bug is UNCONFIRMED, then you can leave a comment on the bug report, indicating that you would like to be assigned the bug report for fixing. At that point it would be good to CC yourself on the bug report. This will allow you to be copied in on any information that is related to that bug. There are two reasons for this:

1. UNCONFIRMED bugs have not yet been investigated by RunRev. It is necessary for RunRev to confirm a bug and elevate it to NEW before a fix can be implemented. If we are unable to confirm the bug you may be able to provide vital information that helps us confirm the bug.
2. The turnaround time for some bug fixes are very short for us inhouse and some bugs are critical needing to be addressed very quickly. In these cases, a bug report would only be assigned to someone at RunRev Ltd.

Q: What should l do if the required work for a fix looks bigger than what would normally be expected for a bug fix and requires wider engine changes?
A: If a fix turns out bigger than you had expected, then it probably does not fit the definition of a bug. In this case leave a message on the bug report to indicate your concerns. The Quality Control Center administrator reads every message and can channel requests and concerns to the in-house technical staff.

Q: Do I have to make the status change, when I am assigned to a bug report?
A: Not at all. You do not have to worry about the status of a bug report. The Quality Center administrator will ensure that the status of your report is changed according to the actions that are required.

Q: Where should I discuss engine level technical related issues?
A: If you would like to get further information on technical issues that relate to the engine, then you can discuss these in the contributors discussion forum.

Regression Fixing Process (how do I fix a bug that was caused by one of my patches)

1. Make sure the regression bug can be reproduced and has a bug number.
2. Request from the Quality Control Center that the bug is assigned to you.
3. Make the regression fix on the maintenance or development branch and ensure you track updates.
4. Submit a pull-request for the fix when you have completed the work on the bug.
5. If you discover that the problem is caused by a flaw in the original bug-fix, or is a flaw in the feature, then please discuss the problem with RunRev Ltd, reverting the patch until you can correct the flaw. Pulling a broken patch, and re-submitting an update at a later date is more appropriate than attempting to fix a broken patch by a sequence of regression fixes.

Adding a Feature

1. (Recommended) Discuss the feature on the contributors forum.
2. (Recommended) Post a proposal for your feature to the contributors mailing list for feedback from RunRev Ltd.
3. Get a fork of the LiveCode repository.
4. Work on your feature.
5. Interact with the pull-request discussion as required to ensure your patch is accepted.
6. If the patch is accepted then the RunRev Ltd team takes on the responsibility of integration.
7. If the patch is not accepted, the RunRev Ltd team will explain why the patch was rejected, allowing you then make any necessary changes and submit a subsequent pull-request at a later date.

Patch Submission and Review

Before submitting your patch please run through the pre-submission checklist:

1. Are you confident your patch is complete and functional?
2. Are you confident your patch has not introduced any issues?
3. Are you confident your patch works on all supported platforms (if applicable)?
4. Are you confident the code in your patch conforms to the coding standards?
5. Have any relevant documentation changes been added to your patch?

If you have answered ‘Yes’ to all the above, post a message with the subject “PULL REQUEST” to the engine-contributors list.

Your patch is then submitted to a variety of automatic tests:

1. Automatically apply the patch to a LiveCode fork.
2. Automatically build the LiveCode installers.
3. Automatically install the LiveCode builds.
4. Automatically run the test system.

If any of the automatic steps fail, then you are notified, allowing you to make the necessary changes and resubmit your patch.

Once all the automatic steps have been completed successfully, the manual steps are executed.

1. The patch is placed into a holding queue, waiting to be reviewed by a RunRev Ltd.
2. The patch is accessed and reviewed by an engine team member at RunRev Ltd.
3. If RunRev Ltd. can validate that all the automatic steps have been completed and the manual code review was successful, then the patch is accepted and applied to the LiveCode source code.

Coding Standard

Coming soon.

Suggested Projects

If you are interested in getting involved in the development of the LiveCode engine project but don’t have a specific idea on what you would like to work on, you should get involved in the user forums. We will be posting project ideas that are not covered by our roadmaps that fit within the existing engine architecture.

Working on the Existing Roadmap

There are a variety of projects on our published roadmap that are ideally suited to crowd development. These projects are usually fairly straightforward in nature but requiring substantial development months. They are also tightly defined and clearly scoped making it easy for many individuals to contribute a few hours or whatever time they can spare.
Getting a large group of community developers working on these specific projects could bring forward releases by weeks and months.
If you are a C/C++ developer and are interested in helping out we recommend subscribing to both the contributors forum and the contributors mailing list where we will be publishing the project plans and how to get involved.

IDE Development

The LiveCode IDE is available in the same GitHub repository as the engine. It is not subject to the GPL license and instead has been released under a more permissive license which can be found in the repository at:

livecode/ide/IDE License.txt

We will be publishing more information on how to contribute to the IDE soon.

Contributions

We are not immediately accepting patches back to the IDE but plan to in shortly. Those interested in contributing are advised to subscribe to the engine contributors forum for upcoming announcements.

Writing Documentation

Improving our documentation is a great way to contribute to the LiveCode project. Our dictionary (API) is the primary place where developers go to understand how to use specific commands, functions and properties.
Updating and adding examples is the easiest way to get started, but we welcome any improvements of the entries.
Each dictionary entry is stored as a single XML file in the main repository:

/docs/dictionary/<entry-type>/entry.xml

Dictionary Entry Guidelines

The logical sections of a dictionary entry are constructed with XML tags that encapsulate text, links and references to icons that make up a dictionary entries. The XML tags abstract the information but it is important to understand what information should be placed between the relevant XML tags.
The following list provides guidelines on what information should be included in the relevant XML tags:

• <doc></doc> - The doc tags enclose the entire dictionary entry and serve as begin and end tags of the entry you are writing.
• <legacy_id></legacy_id> - The legacy id is historic and should not be modified. You will find that some entries have an legacy id of some integer value. These values should not be changed.
• <name></name> - The name specifies what the dictionary entry is called. This is the value that appears in the Keyword column of the dictionary.
• <type></type> - The type is displayed in the Type column of the dictionary. This can be one of the following entries:
  • command
  • constant
  • control structure
  • function
  • keyword
  • message
  • object
  • operator
  • property
• <syntax></syntax> - The syntax is displayed in the Syntax column and describes exactly what legal constructs of the dictionary entry are possible.
• <library></library> - The library is usually empty but can be used to group dictionary entries that are to appear in the left hand panel of the dictionary. Value entries include: Browser library, Common library, Database library, Font library, Geometry library, Internet library ...
• <objects></objects> - Not used at present.
• <synonyms></synonyms> - Contains any synonyms that exist for the particular dictionary entry. Dictionary entries are automatically duplicated for each synonym entry. Individual synonym entries are stored between <synonym></synonym> tags.
• <classification></classification> - The classification allows the dictionary entry to be grouped by a category or concept that underlies its functionality. The classification supports the following XML tags:
  • <concept></concept>
  • <category></category>
• <references></references> - The references refer to other dictionary entries that are relevant to the current dictionary entry. These references have the following format:
  • <command tag=""> Command</command> - References to commands.
  • <constant tag=""> Constant</constant> - References to constants.
  • <control_st tag=""> Control Structure</control_st> - References to control structures.
  • <function tag=""> Function</function> - References to functions.
  • <keyword tag=""> Keyword</keyword> - References to Keywords.
  • <message tag=""> Message</message> - References to Messages.
  • <object tag=""> Object</object> - References to Objects.
  • <operator tag=""> Operator</operator> - References to Operators.
  • <property tag=""> Property</property> - References to Properties.

The information appearing in quotes “” is the exact name of the dictionary entry that is referred to in the references.

• <history></history> - The history allows update information that is relevant to the dictionary entry to be captured and displayed as part of the dictionary entry. The following history tags are available:
  • <introduced version=""></introduced> - The version when the dictionary entry was introduced.
  • <changed version=""></changed> - The version at which the dictionary entry was changed.
  • <deprecated version=""></deprecated> - The version at which the dictionary entry was deprecated.
  • <removed version=""></removed> - The version at which the dictionary entry was removed.

The information appearing in quotes “” is the version number at which the history changed.

• <platforms></platforms> - The platforms specify the operating systems on which LiveCode can run. Relevant icons are inserted next to the Supported Operating System entry on the dictionary entry. Supported tags are:
  • <mac/>
  • <windows/>
  • <linux/>
  • <ios/>
  • <android/>
• <classes></classes> - The classes specify the architectures on which LiveCode can run. The relevant names are inserted next to the the Platform entries on the dictionary entry. Supported tags are:
  • <desktop/>
  • <server/>
  • <web/>
  • <mobile/>
• <security></security> - The security specifies any security considerations that are required when using the specific dictionary entry. Supported entries are the following:
  • <network/>
  • <disk/>
  • <printing/>
  • <process/>
• <summary></summary> - The summary describes, usually in a single sentence, what the dictionary entry does or is used for.
• <description></description> - The description encloses the explanatory context of the dictionary entry and can contain the following tags:
  • <overview></overview> - The overview explains in a little bit more detail what is covered in the summary.
  • <parameters></parameters> - The parameters specify the values that can be passed to the dictionary entry. The parameters can have a complex structure and relevant XML tags have been set up to accommodate this:
    • <parameter></parameter> - The start of a new parameters section.
      • <name></name> - The name of a parameter.
      • <description></description> - The description of a parameter.
      • <option title=””></options> - Specifies the title for a number of options that may follow. The title is enclosed in quotes “”.
        • <option></option> - Encloses the option information.
          • <item></item> - The name of the parameter item.
          • <description></description> - The description of the parameter item.
  • <value></value> - The value describes the information that is returned when calling the syntax described in the dictionary entry.
  • <comments></comments> - The comment should demonstrate how the dictionary entry is to be used. This includes any input and output parameters that may be required or returned. Within the description it is also possible to refer to other dictionary entries using the tags that are referred to under <references></references>.
• <examples></examples> - The examples allow a number of possible dictionary entry uses to be included that are displayed in the dictionary entry. Each example is is encapsulated in <example></example> tags.

This is the XML Schema for Dictionary entries

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="doc">
<xs:complexType>
<xs:sequence>
<xs:element name="legacy_id" type="xs:integer"/>

<xs:element name="name" type="xs:string"/>

<xs:element name="type">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="command"/>
<xs:enumeration value="constant"/>
<xs:enumeration value="control structure"/>
<xs:enumeration value="function"/>
<xs:enumeration value="keyword"/>
<xs:enumeration value="message"/>
<xs:enumeration value="object"/>
<xs:enumeration value="operator"/>
<xs:enumeration value="property"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="syntax">
<xs:complexType>
<xs:sequence>
<xs:element name="example" type="xs:string" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="library" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Browser library"/>
<xs:enumeration value="Common library"/>
<xs:enumeration value="Database library"/>
<xs:enumeration value="Font library"/>
<xs:enumeration value="Geometry library"/>
<xs:enumeration value="Internet library"/>
<xs:enumeration value="Printing library"/>
<xs:enumeration value="Profile library"/>
<xs:enumeration value="Speech library"/>
<xs:enumeration value="SSL library"/>
<xs:enumeration value="Video library"/>
<xs:enumeration value="XML library"/>
<xs:enumeration value="XML-RPC library"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="objects">
<xs:complexType>
<xs:sequence>
<xs:element name="androidBrowser" minOccurs="0"/>
<xs:element name="androidPlayer" minOccurs="0"/>
<xs:element name="androidScrollbar" minOccurs="0"/>
<xs:element name="androidTextInput" minOccurs="0"/>
<xs:element name="button" minOccurs="0"/>
<xs:element name="card" minOccurs="0"/>
<xs:element name="field" minOccurs="0"/>
<xs:element name="graphic" minOccurs="0"/>
<xs:element name="group" minOccurs="0"/>
<xs:element name="image" minOccurs="0"/>
<xs:element name="iosBrowser" minOccurs="0"/>
<xs:element name="iosMultiline" minOccurs="0"/>
<xs:element name="iosPlayer" minOccurs="0"/>
<xs:element name="iosScrollbar" minOccurs="0"/>
<xs:element name="iosTextInput" minOccurs="0"/>
<xs:element name="player" minOccurs="0"/>
<xs:element name="scrollbar" minOccurs="0"/>
<xs:element name="stack" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="synonyms">
<xs:complexType>
<xs:sequence>
<xs:element name="synonym" minOccurs="0" maxOccurs="unbounded" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="classification">
<xs:complexType>
<xs:sequence>
<xs:element name="category" minOccurs="0" maxOccurs="unbounded" type="xs:string"/>
<xs:element name="concept" minOccurs="0" maxOccurs="unbounded" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="references">
<xs:complexType>
<xs:sequence>
<xs:element name="command" minOccurs="0" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="tag" type="xs:string"/>
</xs:complexType>
</xs:element>

<xs:element name="constant" minOccurs="0" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="tag" type="xs:string"/>
</xs:complexType>
</xs:element>

<xs:element name="controlstructure" minOccurs="0" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="tag" type="xs:string"/>
</xs:complexType>
</xs:element>

<xs:element name="function" minOccurs="0" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="tag" type="xs:string"/>
</xs:complexType>
</xs:element>

<xs:element name="keyword" minOccurs="0" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="tag" type="xs:string"/>
</xs:complexType>
</xs:element>

<xs:element name="message" minOccurs="0" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="tag" type="xs:string"/>
</xs:complexType>
</xs:element>

<xs:element name="object" minOccurs="0" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="tag" type="xs:string"/>
</xs:complexType>
</xs:element>

<xs:element name="operator" minOccurs="0" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="tag" type="xs:string"/>
</xs:complexType>
</xs:element>

<xs:element name="property" minOccurs="0" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="tag" type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="history">
<xs:complexType>
<xs:sequence>
<xs:element name="introduced">
<xs:complexType mixed="true">
<xs:attribute name="version" type="xs:decimal"/>
</xs:complexType>
</xs:element>

<xs:element name="changed" minOccurs="0">
<xs:complexType mixed="true">
<xs:attribute name="version" type="xs:decimal"/>
</xs:complexType>
</xs:element>

<xs:element name="deprecated" minOccurs="0">
<xs:complexType mixed="true">
<xs:attribute name="version" type="xs:decimal"/>
</xs:complexType>
</xs:element>

<xs:element name="removed" minOccurs="0">
<xs:complexType mixed="true">
<xs:attribute name="version" type="xs:decimal"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="platforms">
<xs:complexType>
<xs:sequence>
<xs:element name="android" minOccurs="0"/>
<xs:element name="ios" minOccurs="0"/>
<xs:element name="linux" minOccurs="0"/>
<xs:element name="mac" minOccurs="0"/>
<xs:element name="windows" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="classes">
<xs:complexType>
<xs:sequence>
<xs:element name="desktop" minOccurs="0"/>
<xs:element name="server" minOccurs="0"/>
<xs:element name="web" minOccurs="0"/>
<xs:element name="mobile" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="security">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="disk"/>
<xs:enumeration value="network"/>
<xs:enumeration value="printing"/>
<xs:enumeration value="process"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

<xs:element name="summary" type="xs:string"/>

<xs:element name="examples">
<xs:complexType>
<xs:sequence>
<xs:element name="example" minOccurs="1" maxOccurs="unbounded" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="description">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element name="overview" type="xs:string"/>
<xs:element name="parameters">
<xs:complexType>
<xs:sequence>
<xs:element name="parameter" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="options">
<xs:complexType>
<xs:sequence>
<xs:element name="option">
<xs:complexType>
<xs:sequence>
<xs:element name="item" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="value" type="xs:string"/>
<xs:element name="comments" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>