Pxml File Format Defintion

[Svartalf]

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.

The big deal with "unpacking manually" is that someone can add something not specifically made for the Pandora but was built under ARM (Heh... Beagleboard, N800, etc...) onto the Pandora and to be able to be added to the launcher easily. A .desktop or PXML file would accomplish this easily without requiring special tools. Besides, there's a minimal gain in size and since they're as small as they are, you won't really gain anything in speed processing them.

 

[bzar]

+1 for the pure XML
-1 for the .desktop

.desktop -files in my opinion are not software description files, but launchers. Using them as the suggested PXML would be plain wrong IMHO. If anything, a GUI could make .desktop launchers based on PXML files.

Pure, correct and DTD'd XML is the way to go to provide an expandable, readable and well-defined software descriptions. Categorization should not be dictated, but suggested by PXML files. The user could make the calls whether to adhere by personal preference.

Also, a custom extension for pandora software zips would be a good idea to ease installation (basically a zip file, but with an extension of .pzip or something).

 

[salasq]

Also, a custom extension for pandora software zips would be a good idea to ease installation (basically a zip file, but with an extension of .pzip or something).

Custom extensions are PITA - you'd still want common unpackers to grok the files w/o tweaking. Easier to use 'filename.pandora.zip' or somesuch.

 

[bzar]

Also, a custom extension for pandora software zips would be a good idea to ease installation (basically a zip file, but with an extension of .pzip or something).

Custom extensions are PITA - you'd still want common unpackers to grok the files w/o tweaking. Easier to use 'filename.pandora.zip' or somesuch.

So a general zip file manager would open any .zip unless it's .pandora.zip, which would be opened by a software installer? If this is easy to implement I have no objection. I had this idea of install-from-browser in my head . I have never tried to make filename extension bindings that weren't mutually exclusive.

The ideology would basically be the same as in the opendocument format, which (IIRC) is a regular zip file with a custom extension because of its typical use-case differs from that of a zip file. In the case of opendocuments that would be opening them in an office application, in the case of pandora application zip files, installing the software.

I know from previous posts "software installation" in the case of the pandora is mainly unzipping the application to a desired location, but a specialized installer could do other things on the side like verify the zip contents (for example PXML integrity), check for earlier installations of the same software etc.

 

[multiplex]

+1 for the pure XML
-1 for the .desktop

.desktop -files in my opinion are not software description files, but launchers. Using them as the suggested PXML would be plain wrong IMHO. If anything, a GUI could make .desktop launchers based on PXML files.

Pure, correct and DTD'd XML is the way to go to provide an expandable, readable and well-defined software descriptions. Categorization should not be dictated, but suggested by PXML files. The user could make the calls whether to adhere by personal preference.

Also, a custom extension for pandora software zips would be a good idea to ease installation (basically a zip file, but with an extension of .pzip or something).

I don't understand why people want to make .desktop files from PXML? :huh:
Most current Linux software already has a .desktop file. No current software has a released PXML file.

I wouldn't say there's anywhere near a clear distinction either, when you can convert one into the other...
I don't care much one way or another, as I'm not writing a GUI. The XML files look a bit nicer, .desktop files sans the Pandora specific stuff are readily available, and are a standard.

BTW, .desktop files can be parsed e.g. as GLib's key-value files. I'm sure we all know a couple of XML parsers. GLib can parse a subset of XML, too, but it has to be UTF-8 and use only a handful of specified entities...

 

[salasq]

So a general zip file manager would open any .zip unless it's .pandora.zip, which would be opened by a software installer? If this is easy to implement I have no objection. I had this idea of install-from-browser in my head . I have never tried to make filename extension bindings that weren't mutually exclusive.

Apologies, I had a different usage scenario in mind. In this particular case, yes, a custom extension would be of more use.

Why go for .pzip, though, where .pandora would do as well?

 

[bzar]

So a general zip file manager would open any .zip unless it's .pandora.zip, which would be opened by a software installer? If this is easy to implement I have no objection. I had this idea of install-from-browser in my head . I have never tried to make filename extension bindings that weren't mutually exclusive.

Apologies, I had a different usage scenario in mind. In this particular case, yes, a custom extension would be of more use.

Why go for .pzip, though, where .pandora would do as well?

The idea is the same as in pxml. "This is a zip, which contains a pandora application."

 

[.Gogeta§§J4BR.]

you have to think of the purpose first and the tool second.
skeezix points are valid.

 

[nubie]

My concern is with the scanning.

Unless the filesystem loads in a fraction of a second and has a method of obtaining the latest file activity from that information so that it can tune the search.

So we would have 2 searches, one for everything, and one for just the latest stuff on the card. I hope I am being clear enough.


Either that or place all of the desktop files into a single place and have them edited for the path, or even merged into a single cache (that loads quickly, can be backed up, and can be re-built)

I am afraid we are looking at a solution that must pick 2 out of these three: Fast, Powerful, Simple.

I just have a niggling worry that while this will function it will be slow and power-users will be unsatisfied and forced to use work-arounds while an automatic system tries to foil their efforts.

I may be confused as to how this will work in practice, if it is fast enough then I am OK with it as defined. Especially if we can edit entries from the menu just like Gmenu2X, especially if they are corrupted and/or point to an incorrect location.

 

[peca]

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.

Hmm, I like categories for quick sorting new apps. But you are right, only e few standard categories. But users must have an option to make their own categories. Or, maybe, whole idea about categories is wrong and user just sort SW someself.

---
I just recall my experience with Palm and some launcher (Launcher III or LaunchEm or so) and it has tabs for sorting SW and setting for automatic sorting new SW and data by type. Each "file" (called database) on PalmOS have 2 IDs (creator ID and one more that I don't remember) and the launcher sorting newly uploaded SW by this IDs on tabs by user settings. Maybe something similiar can be used on Pandora.

 

[sebt3]

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..


Use inotify. This way you'll be informed of file-change by the kernel without having to pool the disk. The kernel handle every single write on disk so.

And by the way, the article is very old. Inotify is part of the kernel since a long time.

I hope to be helpfull.

cheers

 

[slygamer]

Did this fracture into two camps (XML vs. .desktop) or was there a consensus? Or do we just need someone to say "This is the way it will be"?

 

[andy_js]

PXML is a bad idea.

The freedesktop.org .desktop and mime database should give you everything you need.

We want pandora apps to work regardless of whether the user is using gmenu or xfce... or whatever!

Standards are created for a reason.

It wont make any difference to software deployment anyway,
since there are already package formats/systems to handle that.

"This is a zip, which contains a pandora application."
- We don't need this.

What about .debs and their .control files? Its already been done and standardised.

Keep with the standards, keep things compatible.

 

[parag0n]

PXML is a bad idea.

The freedesktop.org .desktop and mime database should give you everything you need.

We want pandora apps to work regardless of whether the user is using gmenu or xfce... or whatever!

Standards are created for a reason.

I fully agree with this, The standard is in place, is fully supported by current Desktop Environments, Extensible enough for us to add our extensions, and there are standard libraries in pretty much every programming language to use it.

 

[sindbad]

PXML is a bad idea.

The freedesktop.org .desktop and mime database should give you everything you need.

We want pandora apps to work regardless of whether the user is using gmenu or xfce... or whatever!

Standards are created for a reason.
I fully agree with this, The standard is in place, is fully supported by current Desktop Environments, Extensible enough for us to add our extensions, and there are standard libraries in pretty much every programming language to use it.Yep, established standards that work are best.

 

[PSyMastR]

.desktop is more of a launcher, and is hideous to write.

+1 for PXML only if in pure xml, or simple tags that are easy to parse.

 

[Squidge]

This device needs to be simple to use first, and Ubuntu standard second. Lets not dump them on a blank screen with a cursor and a few icons and go "Get on with it". Give the people a simple to use interface, and let the more advanced people use there own more advanced Window managers if they want.

Therefore +1 for PXML (Although I must agree pure XML is better).

No doubt the more advanced users can convert to .desktop or whatever as they see fit.

 

[parag0n]

Using .desktop or pxml makes no difference from the gmenu POV, and would make no difference to the usability of the default OS, except that it would be easier to develop it in the first place because there exist libraries for using the freedesktop standard (.desktop files).

What .desktop does provide over .pxml is BACKWARDS compatibility, it is a Linux standard, used in pretty much every existing Desktop Environment (gnome / kde / xfce / ICEwm).

There is no reason at all for us to reinvent the wheel, and this system would make it EASIER for developers to add a link in, due to the huge amount of existing freedesktop support infrastructure.

I personally support .pzip or similar distribution packages, containing a metadata file (AppName.desktop), and the binaries / support data for the program. I would like to use these .pzip bundles as application directories, similar to macosx's .app folders, where (to the user) they appear as applications without needing any installation at all, just download & play!

+1000 for .Desktop and .pzip for packaging

 

[sindbad]

Simplified installers with package manager backends (like the ubuntu add/remove app) get metadata from .desktop files and they do it quite well. Take a look at how those work.

Please don't get the NIH syndrome.

 

[johnx]

I was in favor of pxml, until I talked with parag0n on IRC. I really think that that any shortcomings in .desktop can be worked around and that working around them is worth it. This makes the pandora desktop-neutral. If we adopt pxml now and individual users (or the official devs!) decide to switch desktops later we'll have to drag our own custom formats along with us and integrate them into other desktop's menu systems. I'd settle for a compromise though: If there was a way to easily parse a pxml and generate a .desktop file would be perfectly acceptable to me. Thoughts?