Pxml File Format Defintion

[cosam]

I like the PXML idea, but I'd agree that .desktop files would probably be adequate, assuming the x-pandora-* extensions don't start to outnumber the standard fields.

If it does end up being XML, you have another vote for making it compliant, and one for removing the BBCode stuff. The major advantages of XML are its standard formatting and the fact that it separates content from presentation. Adding non-standard (and unnecessary) separators and formatting markup would be defeating the object.

 

[EvilDragon]

Well, I have .desktop files... and I hate them.
I always have problems with them on my Linux PC.
Is it possible to include all the options we need for the Pandora and various GUIs?

 

[kanzlr]

either way is good. I am an XML nut myself, but +1 for the .desktop files if they can do what you want to achieve.

 

[multiplex]

True about the .desktop files. I had a look at the specification, and it's not as bloated as I thought I remembered.

The example file could be something like
CODE
[Desktop Entry]
Type=Application
Name=Program Title
Name[de]=Program Title in German Language
Name[it]=Program Title in Italian Language
Comment=This is the English description of the file.\nCan use multiple lines.
Comment[de]=The German Description
Comment[it]=The Italian Description
Icon=program.png
Exec=program.exe -parameter %F
Categories=Main category;Subcategory 1;Subcategory 2;X-Alternate category;X-Alternate subcategory;
MimeType=image/jpeg;image/bmp;image/gif;
Path=../differentdir

X-Pandora-standalone=true
X-Pandora-preview=./preview/pic1.jpg;./preview/pic2.jpg;
X-Pandora-author-name=EvilDragon
X-Pandora-author-website=http://www.openpandora.org
X-Pandora-version=v1.0
X-Pandora-osversion=1.0.0
X-Pandora-clockspeed=600
X-Pandora-background=true



Use some custom lookup rules for the icon/exec file (relative from the .desktop file), and that should work.
Using .desktop files makes a whole lot of sense if you can get it to where you just need to drop the program binary, the icon and the .desktop file together in a folder, and it'll just work.

Differences/issues from the XML file:

• I'm not sure how to handle the different command line options for different file formats.
• Also, going with mime types means you need some other way to specify a extension-mime type relationship for uncommon file types.
• The standard `categories` field in .desktop files assumes that the hierarchy is defined elsewhere, so you just list any categories and subcategories.
• I dropped the BBCode.

I'm not sure I understand quite what the 'standalone' option does, and why it has to be mandatory? If using a .desktop file, it would be nice not to have any of the pandora-specific settings be required.
It seems strange to have 'background' default to 'yes'. Don't most applications run in the foreground?

And another mistake in the example XML: You shouldn't respecify attributes like 'lang' in the closing tags:
<tag attr="foo"></tag>, not <tag attr="foo"></tag attr="foo">

 

[icurafu]

Would it be worth having a hash or signature of the executable?

I like xml personally. And it should be used by default just because it is open and this is an open project.

 

[yosh64]

hey

Just had a quick fly through this thread. Anyhows as others have already mentioned it's pretty much the same as the .desktop files.

Personally I like them, as I don't have to worry about organising my menus, as they are just automatically built using the .desktop files in XFCE . Also, the .desktop files are used for file associations (see the MineType entry), but nevermind.

BTW, I don't understand why ya would use XML when it's not needed for such a thing. I mean, I think they are complex and so take longer to load. Hmm, I think usually folks depend on extra libs for processing XML formats, which I think is a bit of a pain. Anyhows I have no probs with ya using XML, nor with the the standard, I just thought it might be wise to think if it's the best option. edit: I guess folks could hack together a fast loader which doesn't parse or consider the XML hierarchies and what not.

Also, remember if an application doesn't come with a .desktop file, or you don't like the one supplied you can easily change. I have all those I have changed myself in my ~/.local/share/applications directory .

cyas

 

[Squidge]

Would it be worth having a hash or signature of the executable?

For what reason?

 

[bigbottombill]

Why not support both PXML and .desktop formats.
It wouldn't be that hard and we get the best of both worlds

 

[sindbad]

.desktop have the advantage of already being an established standard for starting and otherwise managing apps (there is code to deal with them), being MUCH easier to read and also being faster to parse.

I really hope you stay away from xml. It has it's uses, but it should be avoided when not necessary.

 

[Yannick]

I really like the idea of pandora games/apps packed in zip files with an XML file. Drag 'n' Drop deployment

But you would need to define how these should integrate in a standard Linux distro with apt/rpm.
for example:
extract the zip files in /opt/pandora/packagename/
use a command line tool to generate a .desktop file

this would make it a complete standard

 

[icurafu]

hash/signitures can mean that you could store all of the xml definitions somewhere and then scan your executables on the SD card to match with the xml.

So, lets say that there are some non-conformist developers out there; perish the thought I know, but anyway, these rascals will be releasing these applications without the correct xml and what not. So once it becomes offically apart of the OpenPandora repository, a scan (Maybe built into the OS upon execution) will determine that this binary needs to be stamped with the XML and jpeg or whatever needs to be downloaded to make it work with the OS.

Another is the allowing new GUIs to retro scan and add enhancements, so you can have tags added automatically without having to update the distribution for every binary.

Also, ports to the official tree of a big project such as ScummVM would not always update the xml file. People who just grab it from the offical site would need to executable to be detected as registered in the repository, so that an exact match can be made and updated correctly in the future.

Anyway, there are many many many reasons to have some kind of hash in a identifying XML file would typically be machine stamped when added to the repository.

Not sure if you what I wrote is easy to understand.

 

[AireTamStorm]

Shouldn't some of these things be defined in the launcher rather than the application? I know for one thing that normal window managers have their own ways of defining file associations. Lets say you have two SNES emulators. Both are assigned to files with .smc in their name, which one gets launched?

Edit (missed the second page) : Yeah, I'll have to agree with the others when it comes to the .desktop files. That way you can use it in every window manager, and nothing is specific to gmenu2x. Plus, it doesn't matter if the applications are zipped or packaged. You can create .desktop files from any decent window manager.

 

[Dutch_Cap]

Concerning designing XML formats, this article I bookmarked recently might prove useful.

.desktop doesn't seem to support relative paths for its executables. I think it was designed with a slightly different purpose in mind.

I support XML or something similar, as long as there are lots of standard libraries for parsing the thing.

If speed is an issue (SD cards!), we might want to consider a binary format. This would be faster to read and faster to parse. The binary file could be generated from the XML, by the author or on the fly.

 

[aissen]

Differences/issues from the XML file:

• I'm not sure how to handle the different command line options for different file formats.
• Also, going with mime types means you need some other way to specify a extension-mime type relationship for uncommon file types.
• The standard `categories` field in .desktop files assumes that the hierarchy is defined elsewhere, so you just list any categories and subcategories.
• I dropped the BBCode.

I'm not sure I understand quite what the 'standalone' option does, and why it has to be mandatory? If using a .desktop file, it would be nice not to have any of the pandora-specific settings be required.
It seems strange to have 'background' default to 'yes'. Don't most applications run in the foreground?

Very good analysis.
For the mime types, I’d register the extensions with something like application/x-ext where ext is your extension.

If you look at gmenu2x launcher format, it’s very close to a .desktop file.

Why not support both PXML and .desktop formats.
It wouldn't be that hard and we get the best of both worlds

It’s possible, but the goal of ED’s proposal in the first place was to have 1 standard, widely used by everyone

If speed is an issue (SD cards!), we might want to consider a binary format. This would be faster to read and faster to parse. The binary file could be generated from the XML, by the author or on the fly.

Bad idea, you won’t have any gain on parsing (IO will certainly the bottleneck), and you won’t have any IO gain with smaller binary files, since any xml/desktop will be small enough to fit in a filesystem block... And there will be the hassle of non-hand editable files.

 

[Svartalf]

Bad idea, you won't have any gain on parsing (IO will certainly the bottleneck), and you won't have any IO gain with smaller binary files, since any xml/desktop will be small enough to fit in a filesystem block... And there will be the hassle of non-hand editable files.

The main concern is hand editability, so that someone can manually install or move an "application" to varying places with ease without needing a special application for that task. The filesize delta between an XML versus binary file is in the noise floor, really. If this were going to be more than a K or so of storage, I might concur.

As for .desktop files... That might be usable. Before we make a decision either way (i.e. Adopt our own .desktop key types for this...) we probably ought to see how tightly tied the Maemo implementation for the Nokia series web tablets is- if it's tied tightly to Hildon, like the KDE and GNOME processing stuff seems to be, we may have to reimplement the wheel here and .desktop loses over timing to get this all going. There's already XML processing engines that can handle all of this that are completely detached from the desktop environment that uses the configuration. If it's detatched or there's a standalone I don't know about, since everyone else is doing it that way, we probably ought to consider that instead.

 

[Squidge]

The main concern is hand editability, so that someone can manually install or move an "application" to varying places with ease without needing a special application for that task. The filesize delta between an XML versus binary file is in the noise floor, really. If this were going to be more than a K or so of storage, I might concur.

To unpack manually, you just unpack the zip archive to somewhere (preferably its own directory, as then you can just move the dir if you want it elsewhere). No special application or hand editing of the xml is required.

 

[javaJake]

Well, I have .desktop files... and I hate them.
Agreed. I know XML can be a pain to type out, but that's because it's got the power to expand wherever needed. In my opinion, this .desktop format would do well to learn or thing or two from XML, instead of HTTP headers.

Why not support both PXML and .desktop formats.
It wouldn't be that hard and we get the best of both worlds
No, this is a bad idea. When you require two standards, some developers are bound to go with one or the other.

Perhaps, to make the .desktop people happy, there should be a XML-to-.desktop file conversion script? Would this do?

CODE

#!/bin/bash

# Must have exactly two arguments
if [[ "$2" == "" || "$3" != "" ]]; then
echo "Usage: $0 <XML file> <new .desktop file>"
exit 256
fi

xml_file="$1"
desktop_file="$2"

l=0
lines[l]="[Desktop Entry]"; ((l++)); lines[l]=""; ((l++));
lines[l]="Type=Application"; ((l++)); lines[l]=""; ((l++));
lines[l]="Name="; ((l++)); lines[l]="software/title"; ((l++));
lines[l]="Comment="; ((l++)); lines[l]="software/description"; ((l++));
lines[l]="Exec="; ((l++)); lines[l]="software/exec"; ((l++));
lines[l]="Icon="; ((l++)); lines[l]="software/icon"; ((l++));
lines[l]="X-Pandora-standalone="; ((l++)); lines[l]="software/standalone"; ((l++));
lines[l]="X-Pandora-preview="; ((l++)); lines[l]="software/preview"; ((l++));
lines[l]="X-Pandora-author-name="; ((l++)); lines[l]="software/author/name"; ((l++));
lines[l]="X-Pandora-author-eMail="; ((l++)); lines[l]="software/author/eMail"; ((l++));
lines[l]="X-Pandora-author-website="; ((l++)); lines[l]="software/author/website"; ((l++));
lines[l]="X-Pandora-version="; ((l++)); lines[l]="software/version"; ((l++));

for (( l=0; l<${#lines[@]}; l+=2 )); do
xml_path="${lines[(($l+1))]}"

if [[ "$xml_path" != "" ]]; then
xml_value="$(xml sel -TB -t -v "$xml_path" "$xml_file")"
fi

echo "${lines[$l]}$xml_value" >> $desktop_file
done


Just a quick example of what it could be like.
Edit: Oh, that script requires xmlstarlet, by the way.

.desktop have the advantage of already being an established standard for starting and otherwise managing apps (there is code to deal with them), being MUCH easier to read and also being faster to parse.
But that doesn't mean we have to use them. XML is better in a multitude of ways, and is not difficult or slow (at least, it's not that bad) to parse at all.

BTW, I don't understand why ya would use XML when it's not needed for such a thing. I mean, I think they are complex...
They aren't really. The complex part is making the schema definition part, but I just wrote one up.

Also, remember if an application doesn't come with a .desktop file, or you don't like the one supplied you can easily change. I have all those I have changed myself in my ~/.local/share/applications directory .
And there's no reason why this XML format can't operate the same way. :rolleyes:

I honestly love the XML idea and hope this is what gets included with the Pandora.



To EvilDragon:

The format you presented isn't valid XML, but it's very close. Really all you need is a surrounding tag, so I just added <software></software>. I also wrote up an XSD file so any .xml files written can be validated.

This is my first XSD (from scratch) so I wasn't able to get the ISO language bit working, as I don't know how to apply an attribute to a simpleType. Everything else is functioning, though.
CODE

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

<!-- PXML Software Definition -->
<xs:complexType name="software">
<xs:sequence>
<xs:element name="title" type="humanstring" />
<xs:element name="description" type="humanstring" />
<xs:element name="standalone" type="xs:boolean" />
<xs:element name="icon" type="xs:anyURI" minOccurs="0" />
<xs:element name="preview" type="xs:anyURI" minOccurs="0" />
<xs:element name="author" type="human" minOccurs="0" />
<xs:element name="version" type="xs:string" />
<xs:element name="exec" type="xs:anyURI" />
</xs:sequence>
</xs:complexType>

<!-- Type Definitions -->

<xs:simpleType name="humanstring">
<xs:restriction base="xs:string" />
<!-- <xs:attribute name="lang" type="isocode" /> Optional by default. (Couldn't get this to work. No doubt this is wrong somehow.) -->
</xs:complexType>

<xs:simpleType name="isocode">
<xs:restriction base="xs:string">
<xsattern value="[A-Z]{2,3}|[0-9]{3}" />
</xs:restriction>
</xs:simpleType>

<xs:complexType name="human">
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="website" type="xs:anyURI" minOccurs="0" />
<xs:element name="eMail" type="xs:string" minOccurs="0" />
</xs:sequence>
</xs:complexType>

</xs:schema>

 

[skeezix]

Not had a chance to read the file (Sorry, baby napping on me makes it hard) but let me add, as someone who has been down this road

(I like XML, but whatever. I do't think it shoudl be full heavy XML, just XML-like in that it has XML-tags, but without bothering with full DTDs etc. I wrote an XML parser in about 150 lines of code thats damned fast, but doesn't care about DTD and all that

1) DO NOT use categorization in the descriptor.

Huge mistake.

It makes it hard for people to customize, and more to point.. its only purpose is as a hint, and generally only useful on filesystems with one direcvtory (ie: a big soupy mess.) In those cases, you neerd some categorization system.

It is almost alwaysfar superior to let the user categorize by directory structure all their own.

(Or have the launcher allow a directory as category, and also a 'suggested category'.)

2) If you allow categories (don't!), use tags instead. ie: A ctegory is a word, and you can have multiple of them. ie: An emu ... well its a game, and its an emulator, file it under both. (Tags need not be hierarchical, but you can do that too if you want.)

IF you really want to do categories or tags, you must MUST have a very well defined and very short list of them, and an error to use anything but those.

Otherwise you end up with developers making all sorts of random categories all over the place, with spelling typos and such.

Oh, a launcher should never ever scan the SD card automatically to look for new apps, unless user wants that (Default on maybe, for newbs?) I don't want my 8GB SDHC card being scanned all the time for new files.. especially since those files could arrive in background from a file transfer etc. You don't want to rescan 20,000 files every 30 seconds in background..

Do it on demand

jeff

Thats my suggestion anyway; launcher can look in a couple planned places, and auto-scan those; manual scan can scan the entire fileytem on demand. The Descriptor (whatever format) can suggest a list of 'tags' for the application, and the tasg are form a well defined list. The launcher can show by directory browsing, or by tag listing (user can pick a list of tags to view in a given window. That configuration saved into the browser.)

So therefor I can go to /Apps/TextProcessing or /Games/Emus/Atari directories, say, and have very specific categorization the way I want it. Or I can hit a shoudler button and have it listed by tag-windows (Default is a list of say 5 windows; one for Apps, one for Games, one for System Utils, etc. But I could customize it to have only 1 windo wthat shows Apps+Games tags, say, if I wanted.) Now you've got directoey fore categorization, or Tag windows. Nice and easy, and easily customized.

edit: Oh, for using a vey doiscrete list of categories and tags, in addition to keeping things sane in the organization, it also makes localizaton and language porting easy. ie: If you have category or tag Games or Games-Emus or whatever, then that coudl be the standard descriptor wordsing, but the localizad UI coudl show it in whatever language, because theres a standard lookup table. If you allow arbitrary categories or tags, you get a total mess, and also cannot easily localize it.

 

[yosh64]

hey

Here are the official/standard categories for .desktop, so I thinks anyhows, hehe.

edit
I think applications can fall into multiple categories, from those I've seen usually you have a general category and it moves onto more specific categories. This is pretty cool, for example in XFCE you can have your menus have submenus of the more specific categories of applications, although I prefer to have without submenus, with things together in more general categories.

another
BTW, you can view the .desktop specs in full together HERE, or section by section HERE.

and another
If you want to see some examples of category entries see HERE. As you can see you can also specify what categories for it to show or not show up in.

cyas

 

[Vorporeal]

I don't know if this has been discussed yet, but what about the applications that we'll be installing that aren't developed specifically for the Pandora? All the thousands upon thousands of applications that are floating around on the net that people will want to install? At least having .desktop support would help with integrating those into the launcher. We also might want to think about an easy way to integrate into the launcher those applications/packages that don't have PXML or .desktop files.