PXML specification

Attention: at the present time, the PXML file format isn't set in stone, and is therefore subject to change. There is no guarantee that the format or the schema are bug-free or will be changed at any time. Please wait until this standard is finished before writing a PXML file.

This is the human-readable specification for the PXML file format. The PXML file format is used in your applications for the OpenPandora® that you package in ".pnd"-files or distribute otherwise, to make it possible for menus and launchers to use your applications and their properties.

A PXML file should be appended to your ".pnd"-file, using the tools provided for that purpose, or put in a directory that you want to serve as a redistributable package, to make it possible for launchers and menus to find it. It should have the name "PXML.xml" not case sensitive, and there should only be one such file. The contents of the PXML file should also comply to this specification without exception, to guarantee that everyone will be able to read it.

XML compatibility

The PXML format is XML-based and fully XML-compliant, which means that it can be read and written by any XML reader or writer. Included with this specification should also be a ".xsd"-file, which is used by XML tools to validate PXML files. A ".xsd"-file is also known as a XML schema, and can be called the "computer-readable" version of this document. It is very good practice to validate your PXML-files with that schema before publishing them.

To write a PXML file, you also need to know the basics of writing a XML file. It boils down to the following:

1. If an element contains text or other elements, it needs a start-tag and an end-tag. This looks like (1)
2. If an element does not contain other elements or text, but only attributes, it looks like (2)

<exampleelement someattribute="something">something inside it</exampleelement> <!-- (1) -->
<exampleelement2 someattribute="something" /> <!-- (2) -->

Format

The PXML-file is split up into multiple so-called elements, each of which specify one property of the ".pnd"-package. All of these elements are surrounded with a "<PXML>"-tag, which tells the readers of the file that the data within that tag belongs to a PXML file. The tag and elements should be defined as follows:

The PXML-tag

Description

The PXML-tag serves as the container for all PXML elements. It is the first thing that should occur in your PXML file. An example "<PXML>"-tag would look like this:

<PXML xmlns="http://openpandora.org/namespaces/PXML" id="uniqueID">
  <!--All of the PXML elements should be put here-->
</PXML>

As you can see, the PXML tag accepts a few attributes, namely the "id" and "xmlns" attributes.

• The "xmlns" attribute is required by the XML standard, and guarantees that this file will be identified as a PXML file. You must include the xmlns attribute, exactly as shown, in your PXML file, with the URL as specified. Only then can it be guaranteed that the file will be read at all by launchers and menu apps.
• DEPRECATED; SEE "application" tag. The "id" attribute specifies an identifier for your PND package, and should be something globally unique so that no two PND packages have the same id. This can be achieved by appending some random number to your application name, and to use that as your id; or to simply generate a completely random, very long id. If this id already is used in another PND file, those two PND files will conflict with each other, and unforseeable errors will occur. Please put effort into generating an unique id for your PXML-file.

The Application-tag

Description

The Application-tag permits the PXML.xml container to have multiple applications within it; you should have at least one application tag-pair (for one app), though you may have many.

<application id="uniqueID">
  <!--All of the PXML elements should be put here-->
</application>

• The "id" attribute specifies an identifier for your PND package, and should be something globally unique so that no two PND packages have the same id. This can be achieved by appending some random number to your application name, and to use that as your id; or to simply generate a completely random, very long id. If this id already is used in another PND file, those two PND files will conflict with each other, and unforseeable errors will occur. Please put effort into generating an unique id for your PXML-file.

A good unique-id is the application name, developer name, and some key you may wish to update on occasion (should state-data become incompatible between updates, say.)

Consider: battlejewels.skeezix.001 quake-1.pickle.001

unique-id formatting: Should not include directory or filename invalid characters, such as ?, >, /, etc. Any of those will cause the pnd-file to not function.

Note on Uniqueness: The unique-id should be unique against other pnd-files, but may be re-used by other 'application' tags within the pnd; for example, you may have multiple subapps that want to share the same appdata path (which is formed based on unique-id!), so use the same unique-id. You might then have a utility application in that same pnd, which needs its own appdata, and so gets its own unique-id.

The title element

Description

The title element specifies the text that is shown to the users of your PND file as the application title. This element can be specified multiple times in multiple languages the language is indicated by the lang attribute.

At least one "title"-element is required, in the "en_US" American English language.

Example

<title lang="en_US">Your application name</title>
<title lang="de_DE">Dein Programmname</title>

The description element

Description

The description element specifies the text that is shown to the users of your PND file as the application description. This element can be specified multiple times in multiple languages the language is indicated by the lang attribute.

At least one "description"-element is required, in the "en_US" American English language.

Example

<description lang="en_US">Your long description of this application, describing its purpose and highlighting its features.</description>
<description lang="de_DE">Deine etwas längere Programmbeschreibung, die den Sinn des Programmes und seine wichtigsten Features beschreiben sollte.</description>

The exec element

Description

The exec element should specify all the information needed to execute your application. An exec element must be included in every PXML file. It accepts the following attributes:

• The command attribute specifies the path to the executable file. This should be a relative path to a file within the PND package. Must contain no arguments! One strategy you may need is to point to a sh-script in your pnd-file, which in turn sets up LD_LIBRARY_PATH, determines arguments to pass, uses zenity to pop up a pre-run menu, or other trickery.
• The arguments attribute may be not present, or present with 1 or more arguments to the executable.
• The startdir attribute specifies the starting directory (Also known as the working directory) that the application should start in. This should be a relative path to a directory within the PND package, or to a well-known directory in the Pandora file system.
• The standalone attribute specifies whether or not this application can run on its own, or if it needs parameters to run. A value of "true" or "1" means that the application can be run without parameters. A value of "false" or "0" means that the application must be run with parameters (Meaning that no icon will appear for it in a launcher; it will only be run via file associations or via the terminal).
• The background attribute specifies whether or not this application should run in the background, and it should be possible to switch to other apps while it is running, or if it is the only application that should be running. A value of "true" or "1" means that the application can run in the background. A value of "false" or "0" means that the application must be run as the only application.
• The x11 attribute may be missing; values are one of "req", "stop", and "ignore". If "req" is set, it means the application requires X11 (and possibly could be filtered out of users display in a menu if X is not running, or perhaps such a menu would have to start X.) If "stop" is set, it means X must be not running, or temporarily shut down, for the app. If "ignore" is set, the app doesn't care if X is running or not (such as an SDL app, or a sh-script, etc.)

Example

<exec background="true" startdir="/usr/share/icons/" standalone="true" command="myprogram" arguments="arg1 arg2" x11="option"/>

The icon element

Description

The icon element should specify a nice icon for your program. An icon element is optional. It accepts the following attributes:

• The src attribute specifies the path to the image file used as the icon.

NOTE: Current implementation will use the pnd-file's appended icon; for a PXML-app-directory, it will try to use the icon mentioned in the PXML. So for a pnd-file, all subapps will show the appended-icon, regardless of the <icon> tag within the PXML.xml

Example

<icon src="images/icon.png"/>

The info element

Description

The "info" element allows the PXML.xml to suggest to the desktop environment or menu a file that may be shown to the user when they want to know more - be it an About, a Install Guide, a User Guide, or all of the above.

The file can be a txt-file or an html-file, and as the PXML-app-dir or .pnd-application will be mounted, the file may in turn branch to other files should it wish to.

Developers do not need to have this element, if their app is nice and simple and just runs. If the application requires additional set up (such as Quake requiring separate pak files that cannot be included in the pnd), or if you wish to include sample config files or config guidelines for something complex like DosBox, or include Pandora-specific notes.. those are all good things. But the developer is encouraged to be tasteful and not go hog-wild!

• name -> the name to be shown in the menu; should be obvious that it belongs to the pnd .. Quake's game pnd could have "Quake 1 Setup".
• type -> the mime type for the file; in the event the consuming application can map mimetypes to an appropriate executable, this would be a good way of letting the user's preferred reader come up.
• src -> required A file (including path relative to the pnd; ie: ./index.html would be the root of the pnd) in the pnd to open up; by default, the web browser will likely be used to open it.

Example

<info name="AwesomeGame Setup" type="txt/html" src="index.html"/>

The previewpics element

Description

The previewpics element is an element that contains multiple other elements. A previewpics element is optional.

It contains multiple pic-elements. Every pic-element represents one preview picture. If the previewpics element is specified, it must contain at least one pic element.

• The src attribute on a pic element specifies the path to the image file used as the preview picture.

Example

<previewpics>
  <pic src="preview/pic1.jpg"/>
  <pic src="preview/pic2.jpg"/>
</previewpics>

The author element

Description

The author element is an element that is used by the author to introduce him/herself. An author element is optional. It accepts the following attributes:

• The name attribute specifies the name of the author.
• The website attribute specifies the website of the author.
• The email attribute specifies the e-mail of the author. This attribute is not yet supported by libpnd, but please specify it anyways.

Example

<author name="Bjornhild Andersson" website="http://some.website.with.author.info"/>

The version element

Description

The version element specifies the application version. A version element is required. It accepts the following attributes:

• The major attribute specifies the major version number. This number should be 0 or more.
• The minor attribute specifies the minor version number. This number should be 0 or more.
• The release attribute specifies the release number. This number should be 0 or more.
• The build attribute specifies what build the application is at. This number should be 0 or more.

Example

<version major="1" minor="1" release="1" build="2"/>

The osversion element

Description

The osversion element specifies the application version. An osversion element is optional. It accepts the same attributes as the version element.

Example

<osversion major="1" minor="1" release="1" build="2"/>

The categories element

Description

The categories element is an element that contains multiple other elements. A categories element is required, and must contain at least one category.

Menus that use your PXML in any shape or form will use the category information to sort your application entry into the tree or sub menus. Depending on the menu system, this will be done differently every time. It is therefore advisable to specify as many categories and subcategories as possible (and as suitable; don't specify that your application belongs in a category if it doesn't).

The "categories" element contains multiple category-elements. Every category-element represents one category that this app can be sorted into. Valid top-level categories are (among others):

1. AudioVideo
2. Audio
3. Video
4. Development
5. Education
6. Game
7. Graphics
8. Network
9. Office
10. Settings
11. System
12. Utility

Please see the FreeDesktop specification for more information. In it, you will also find valid subcategories for your top-level categories.

The category-element takes one attribute: The name-attribute. This attribute represents the category name, which preferrably should be one of the above.

A category-element can contain further child-elements: subcategory-elements. These represent the subcategories of a category that the app will be sorted into.

The subcategory-element also takes a name-attribute; this attibute can contain a name for your subcategory.

Example

<categories>
  <!-- This app belongs in the "Game/StrategyGame" category -->
  <category name="Game">
    <subcategory name="StrategyGame"/>
  </category>
  <!-- This app also belongs in the "Graphics/ImageProcessing" category -->
  <category name="Graphics">
    <subcategory name="ImageProcessing"/>
  </category>
</categories>

The associations element

Description

The associations element is an element that contains multiple other elements. An associations element is optional, except if exec.standalone is false.

It contains multiple association-elements. Every association-element represents one file action association.

• The name attribute on an association element specifies the user-friendly action name for the association.
• The filetype attribute on an association element specifies what file types (in MIME format) that this association should apply to.
• The exec attribute on an association element specifies the command-line arguments that should be given to the program, when this action is performed. The exec can contain a "%s", which indicates where the file name of the file, that the action is performed on, should be inserted. For example, if the exec-line is "--file %s --type lol", and you have a file "lol.bmp" that the action is performed on, the exec-line is transformed into "--file "lol.bmp" --type lol"

Example

<associations>
  <association name="Open Bitmap Image" filetype="image/bmp" exec="-f %s --no-deinterlacing"/>
  <association name="Crash the computer with a stylesheet" filetype="text/css" exec="-f %s --crash-on-success"/>
</associations>

The clockspeed element

Description

The clockspeed element specifies what clockspeed this app should run at. Please do only specify this element if your application *needs* to run at the specified clock speed. A clockspeed element is optional. It accepts the following attributes:

• The frequency attribute specifies the wanted frequency, in megahertz (MHz).

Example

<clockspeed frequency="600"/>

The mkdir element

Description

The PXML may request creation of directories on the SD card.

This should be used sparingly.

There are a number of scenarios in which this may be useful; should an application wish to attempt to establish a canonicle location for a file, it can request a path be created. This can avoid user confusion -- user merely plugs in SD, waits a few moments, pulls out SD, and inspects it to see what directories he may populate. Consider 'id' files for Quake -- the user might have many ports of the game, such as Quake, or ioquake, or others. They could all share the same id pak files, but the user may not know where to put them. (Especially since the pnd-file itself does not have user documentation available perhaps.) Consider ROM-paths for emulators .. perhaps the emulator expects ROMs in a specific location? If so, the author may wish to have that location created, to make it obvious.

NOTES The paths are created on the SD that contains the pnd. The paths may not include ".." or wildcards.

It accepts the following attributes:

• dir -> the name of the path to be created; it may not be multiple levels deep - to effect that, include multiple <dir path="..."/> entries

Example

<mkdir>
  <dir path="/foo/bar"/>
</mkdir>

If this is in /pandora/desktop on SD1 (/media/mmcblk0p1 say), then /media/mmcblk0p1/foo/bar will be created.

Example file

<?xml version="1.0" encoding="UTF-8"?>
<PXML xmlns="http://openpandora.org/namespaces/PXML">

  <application id="youruniqueID">

    <title lang="en_US">Program Title</title>
    <title lang="de_DE">German Program Title</title>

    <exec background="true" command="program"/>

    <info name="AwesomeGame Setup" type="txt/html" src="index.html"/>

    <icon src="program.png"/>

    <description lang="en_US">This is the English Description of the file.</description>
    <description lang="de_DE">This would be the German description.</description>

    <previewpics>
      <pic src="preview/pic1.jpg"/>
      <pic src="preview/pic2.jpg"/>
    </previewpics>

    <author name="Some Dudeson" website="http://a.bc.de"/>

    <version major="1" minor="1" release="1" build="2"/>
    <osversion major="1" minor="0" release="0" build="0"/>

    <categories>
      <category name="Game">
        <subcategory name="StrategyGame"/>
      </category>
      <category name="Graphics">
        <subcategory name="ImageProcessing"/>
      </category>
    </categories>

   <clockspeed frequency="600"/>

  </application>

</PXML>

Validation

To validate a PXML file, you need a XSD (XML schema) validator, and you have to know how to use it.

You will also need to put the XML schema for the PXML format in the same folder as your PXML file. Note that the current PXML schema is horribly out of date.

When you have done that, and know how to use it, you need to change a few things in your PXML file. In your PXML tag, change the contents from this...

<PXML id="..." xmlns="http://openpandora.org/namespaces/PXML"> ...

...to this:

<PXML id="..." xmlns="http://openpandora.org/namespaces/PXML" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PXML_schema.xsd"> ...

Now the PXML file can be validated.