Pandora Libpnd - The Pandora Library


skeezix

Internal Development
Joined
Mar 11, 2003
Messages
8,070
Website
www.codejedi.com
I've started entering in documentation to the public pandora wiki.

Since I've got no top-level edit perms, I put the stuff under Development Tools, with a link to the libpnd 'hub', which is here:

http://pandorawiki.org/Libpnd_hub

Its only just begin, but the info is slowly filling in.

NOTE: libpnd defines a lot of stuff about the device, such as how to put files onto SD cards to be runnable. I'm building that documentation into this, but we may need someone to make 'user documentation', since getting users ot read coding docs to find out this sort of thing might be silly :)

Feel free to ask me/us in this thread for information, and it may remind us of a section that is otherwise forgotten.

jeff

(and vimacs who wrote most of the support sh-scripts and helped define the pnd-file system, etc. I'm not alone here!)
 
I don't really know jack about the PND system at all, but I just suddenly wondered:

Can a PND program retrieve a list of the other PNDs that are attached to its Pandora?
Like how some console games will look for other games made by the same company on your memory card.

Edit: PND is the one that's a packaged game that installs automatically, right? I feel like I'm using the wrong acronym here.
 
PND files do not need installation; you just copy them into 'the right places' and you're good to go.

And libpnd supplies functions for discovering what applications are available, yes. Thats one of its primary functions :)

jeff
 
Hey skeezix, I'm a little confused by this:
Basically its just an ISO file with an PXML and an optional PNG icon appended. (cat appfolder.iso app.pxml icon.png > app.pnd)
versus this:
An Icon should be in the root of the directory or .pnd bundle
Can you clarify on where the icon needs to be, or are both ways possible?
 
well, either :)
you can have applications just in a normal folder, in which case you are supposed to have the pxml and the icon in it.

Or you can pack em up as .pnd packages, in that case those two need to be appended, this is done so that the image doesn't have to be mounted/read to get the info while scanning. so a mount only hase to be done when launching which makes the whole scanning amazingly fast with .pnd packages.
 
I shall have to clarify ..

A .pnd file is usually created from a directory; ie: dev makes a directory, puts his executable, datafiles etc in there, and also the PXML.xml and the icon artwork referred from the PXML. He then runs the pnd_make.sh script on the dir and it spits out a .pnd file which is distributable.

So the PXML.xml and icon are in _both_ the dir structure and the .pnd. (and by dir struct I mean the source dir the dev made, but also the dir structure in the .iso which is in the .pnd, follow?)

ie: The icon is _in_ the ISO bits, but for _convenience_ is appended to the iso to make it easy to locate. ie: We can look at a pnd, and with some simple seeks find the icon and the PXML, without even mounting the ISO. But upon thid examination, we can then mount the ISO and find _the works_.

Note that even if the PXML.xml and icon are omitted, they can be located the hard way.. backseeking through the whole ISO to find the bits, since ISO is an uncompressed filesystem. So appending the bits makes it easy and fast to locate, but the system is fail-safe in that they'll still be found even if not appended using pnd_make.sh or equivilent.

(Of course, if there is no PXML.xml at all, the .pnd is invalid and is not 'auto discovered'.)

jeff
 
That makes sense. To summarize: put the PXML and icon inside the project folder, run pnd_make.sh on the project folder, then everything comes out smelling rosy. But if making manually, append PXML and icon to the PND, but keep an extra copy in the ISO as a just-in-case.

Make sure this gets into the wiki page, but I'm sure you already knew that. No rush, I guess, seeing as it's a work-in-progress that few if anyone will need to know right now.
 
skeezix said:
PND files do not need installation; you just copy them into 'the right places' and you're good to go.

And libpnd supplies functions for discovering what applications are available, yes. Thats one of its primary functions :)

jeff

How about adding capability for a standard "uninstallation"? For installation, the user would copy the ".pnd" file to the sd card.
Currently, when uninstalling, they delete the single ".pnd" file, but this wouldn't remove any files the application may have written (to NAND, /some/random/dir, /pandora/appdata/app-id).

ideas:
1) add a tag to the PXML file (or libpnd config files) that specifies the locations where application specific data is written. Then during uninstallation, simply delete those locations.
2) have way(s) to initiate the uninstallation directly from pnd file:
  • right click on pnd icon and select "uninstall"
  • from command line, add an uninstall option for pnd files. example: "mame.pnd --uninstall"
 
Last edited by a moderator:
I believe that the situation is this (or that's what I've been told by skeezix and cpas):
Don't do anything radical with the system that makes it work like traditional packaging systems (install scripts, an "installed"/"uninstalled" status, leaving files around), but otherwise, go wild (if you want a "last modified" field in the PXML, create a patch and wait for approval; or, if you want to "fix" the libpnd PXML API etc)

Also, not even traditional systems clean up config files when you uninstall a package, so why should this one do it? I would be quite annoyed if someone removed my savegames just because I wanted to install a newer version of a game.

Finally, as I've understood it, this isn't the primary packaging system for the Pandora and never will be. I don't see how something like OpenOffice could be packaged in a PND for instance; a PND can host only one executable per instance, and there are only limited file associations. And then we have the classic icon pack examples that we raged about 3 months ago: impossible to accomplish with the current format. Use IPKG if you're doing something else than an application that is only to be launched using a .desktop file, imo.
 
Currently, when uninstalling, they delete the single ".pnd" file, but this wouldn't remove any files the application may have written (to NAND, /some/random/dir, /pandora/appdata/app-id).

I really don't see a need for this.
Pandora applications should never write outside their own folder, doing so causes the writes to be redirected to rootofsdcard/pandora/appdata/appid
so to completely uninstall an app you just remove that folder.
 
Removing the pnd does not remove any user data. IF the app writes back to its pnd/pxml-dir, then it goes to the /pandora/appdata instead. If i writes to somewhere else on the SD, thats its business. But the pnd system never deletes user data, ever. You can manage your own data, as god intended. (ie: Really, you uninstall Word, you want it to wipe all your Word docs? That would be _insane_ ;) IF its well behaved and writes to appdata, then you c an remove the entire data in one delete if you wish, but it shoudl always be upto the user.. this is just like PSP and PS2 and xbox and every machine around.

Uninstallation is delete, move, rename, whatever.. it is as easy as it could possibly ever be :)

To wit, I doubt we're adding anhy features to the system right now. Theres a thing called 'feature freeze' when you get near to launch (and triply so when working in your spare time ;)

jeff
 
Openoffice has one launcher no? I forget. It isn't perfect, but it's also v1.0 right? If it's good enough for90% of apps, that's pretty good for a couple hackers/contribs right? :)

jeff
 
skeezix said:
Openoffice has one launcher no? I forget. It isn't perfect, but it's also v1.0 right? If it's good enough for90% of apps, that's pretty good for a couple hackers/contribs right? :)

jeff
OpenOffice has 5 launchers, each with different file associations. Also, OO needs to store its icons in /usr/share/pixmaps and so on or the UI will look glitchy as heck. Not really suited for PND packaging IMO.
 
Last edited by a moderator:
@dflemstr: ipkg does solve the problem, but not as user friendly (for beginners) as distributing and running a PND file.

@Vimacs: If the application follows the rules, then yes it is simple to delete a single folder at /pandora/application.

@skeezix: I agree, you should never delete user data without their explicit approval. For many applications, when you uninstall, it will ask you whether or not you want to keep your user data.


From the wiki: "When a .pndfile or PXML.xml dir get mounted, any writes back to the mounted area are put into appdata, with a subdir by the unique-id."

Lets say your SD card has over a hundered PND files. Each of which write to their unique-id folder under /pandora/appplication. If you delete 50 of the original PND files, you still have 100 /pandora/application/unique-id folders lying around and depending on how the "unique-id" folders are named, you may or may not know what applications these files are associated with. Also, you don't want to mistakenly delete one of the unique-id folders for a PND which still exists on your SD card.

Perhaps this kind of user file management is better suited for an external PND "uninstaller" manager, tool, or script. There are several ways to approach this problem.

We're nearing the release of the pandora (two more months(TM) right?), so I agree you have to stop making improvements at some point to have a stable release.

Good work on libpnd and pxml guys!
 
overjupiter said:
Lets say your SD card has over a hundered PND files. Each of which write to their unique-id folder under /pandora/appplication. If you delete 50 of the original PND files, you still have 100 /pandora/application/unique-id folders lying around and depending on how the "unique-id" folders are named, you may or may not know what applications these files are associated with. Also, you don't want to mistakenly delete one of the unique-id folders for a PND which still exists on your SD card
Currently the unique-id (when automatically creating the pxml) is exename-randomnumber.
For manually created ones it can of course be whatever the dev wants. We are currently thinking about how to make sure that the name stays meaningful, maybe libpnd will end up always prefixing the application name from the pxml to the id.

Regarding management utility's, i think this is something that could/should be solved by the community later on, its not an essential part to worry about for now.

Also the only places an app can write to (without asking for root rights) is the sd cards and the users home directory, so i don't see much of a problem with fs clutter here.
 
Last edited by a moderator:
Vimacs said:
We are currently thinking about how to make sure that the name stays meaningful, maybe libpnd will end up always prefixing the application name from the pxml to the id.
What about doing what I proposed back when the PXML spec didn't have a "package" field and I was too lazy to add one (But that it now has according to the source), which was to just take the package name and version tuple and use that for the directory? I don't think that there'll be a problem with two developers creating two packages with identical names in a small community like this (it doesn't even happen in Debian so often that you hear about it, so why should it happen here). Because that "id" field always bugged me; it just seemed strange to use an overlay like that. I renamed it from, oh what was it, "overlay-something-or-other" to "id" just to make it a bit more clear what it meant but now it seems that it's being used for more than it was back then...

BTW, if anyone wants to create a *long* discussion about this like what happened a few months ago, please do so in another thread.
 
Last edited by a moderator:
Question, is it possible to access a PND file's folders easily? That could be really useful for things like IDEs.
 
Back
Top