Pandora Directory Structure Question


Dimacus said:
I'm not sure how much of the Quake series media files (pak files) are freeware and can be included in the PND, by default.
This means that you will have a lot of stuff in the appdata folder that the user will have to be aware of (if he wish to remove quake / change pak files etc.)

Now this could just be me not understanding how PND files work, but would not emulators and interpreters such as ScummVM suffer the same problems?
I.e. the data files requires separate manual handling, in a not-very-intuitive (especially for beginners) directory.
I realize that there might not be a solution to this involving PND's, that this sort of application might have to be started (and handled) old-fashion style.
I see your point. There was at one point discussion about allowing PND's write to a place they could all read. This would make it possible to PND-package scummvm games to be used with the actual scummvm PND. Same goes for quake paks. Oh.. ooooooh... Craigix, is this what you meant? PND's being dependant of each other? If this is the case I see the problem and how it relates to DLL hell, but I don't see any easy solution.
Dimacus said:
Personally I like the sound of having a separate folder for every pnd file, containing the pnd-file and a subfolder for it's external data.
It would make backing-up and deletion much easier and more intuitive for most new users.
This kinda walks on the toes of "just drag and drop the pnd". Maybe discovered pnd's could have these folders automatically generated? Then the pnd's could be automatically moved to these new folders. This way we could still have that drag'n'drop that's been touted everywhere :)
 
Last edited by a moderator:
and simply, what about a kind of self contained read/write file system inside the pnd?
 
Elwing said:
and simply, what about a kind of self contained read/write file system inside the pnd?
Oh, so you're experienced in file system design, I see! Well, the Pandora developers would love to get some code from you!

On a more serious note, I think that PNDs (in the case of binaries) and PND folders (for when you extract PNDs) should be strictly read-only.

Think of them as game cartridges: you don't want them to become messy. You'd like to be able to give a PND to a friend without having to include all of your game saves. Or, imagine that a game becomes messed up (because of a bug or whatever) and you want to "reset" it. What's easier: to simply delete an appdata folder, or to open up the PND with a special tool, remove a folder, and sew it back together again, cleaning up the spilt-out blood?

Also, PNDs currently use isofs internally for the file system. isofs isn't an easily expandable file system, which means that if you want PNDs to become mutable, the OS would have to reformat the whole PND every time that you added or removed or changed a file in it (aka it would have to create a new PND that was larger/smaller, copy over all of the data including your changes, and remove the old file). Trust me: NOT a good idea.

The issue of backups: Just make back ups of your "sdcard/pandora" folder and it'll include everything that you need. What's the problem?
 
Last edited by a moderator:
Dimacus said:
conso said:
Preferences and save-files should go to a decent place in one users home-dir, based on certain rules.
And on witch of your sd cards would you want your home dir, on all of them? What happens if you have two cards in at once?

I don't think a home dir is a very good idea on a system where the only writable media you have is removable, not in the common-*nix sense you refer to anyway.
Hadn't seen this reply till now.

Placing the home-dir on an sd would indeed be quite static and not ideal. Currently, the home-folder is on the nand and that's probably the best way to handle that. What could be done though, is letting libpnd handle specific user-folders. Each pnd could contain a tag that tells the needed home-dirs. Like "~/.quake". On start, the system could check if a representing folder exist on the sd, like "/media/sdb1/userdata/$user/.quake" and symlink that folder to "~/" and maybe register that operation for the unmounting process. Afaik libpnd already does similar things with the content in the pnd itself and the appdata.
conso said:
... now we have a decent multiuser-OS and shall throw that away because some users only know how to use a single-user system?
Not some, most (judging from these forums) pandora users will use it as a single user system. (even if they do want a login screen)
And it's not trowing away anything, if I understand the current situation correctly, they have defined a variable to point to a certain place on the sd, if you don't like it, change it.
Well, maybe we imply the same solution to the problem. I don't know how many users want to do multi-user, don't think the number should matter anyway. Linux is a multi-user system by design, we should care about that. Introducing different dogmas will probably result in problems on the long run. The reason why I say anything about that is that pnds shall be the main way to distribute games/apps for pandora and if libpnd doesn't handle multiuser-setups in the nand-installed OS, the same will apply to sd-installed Linux.
conso said:
Goddamn, is this world flooded with "I'm a windows user and always use admin account, everything else is to complicated"-idiots?

And a nice day to you too.
Sorry for the harsh words, totally inappropriate. Can't really tell why I got angry any more.
 
Last edited by a moderator:
Wait a second? WHAT are you all talking about?

The good thing about .PNDs is, that you put them all into one subdirectory and they keep their config files, etc. elsewhere.
That way, you don't need to install anything.

Want to delete the config (because you messed it up, maybe)? Then simply delete the folder of the app in the appdata directory.
Want to delete the app for a while but keep the config? Then delete the PND and keep the folder in the appdata directory.

It's that easy.

You want to have the datafiles and configs in the SAME directory as the PNDs?
Heck, if I have 50 PNDs in my menu directory, I surely don't want to have 50 config files in this directory... THAT would be messy and cluttered.
That would like putting ALL games and configs into ONE directory (without subdirectories)... is anyone doing that on the WIZ or GP2X??

This is no way anything like a DLL hell, as the app will have ALL THE DATA NEEDED in it's PND! (except for datafiles like Quake, etc. which we can't offer).

So if you delete the appfolder, the program won't stop working, it would just be as if you had just installed it fresh on the SD card.

You can simply download an app from the appstore, save it to the PND-folder - and run it. It works, I tried it. It appears instantly. And it does save its config files in the appdata-directory.

Here's how it works:
i.e. if you download SuperTux, you download the SuperTux.pnd and place it in the menu or the desktop folder. It will automatically appear in the menu or on the desktop.
You run it and change the configuration (button config, etc.).
It then creates a folder named "SuperTux" within the appdata directory. That's where your savedata is in.

Now, somebody created new maps you want to try out. Simply place them within the SuperTux-Directory in the appdata-Dir and run it. It works.
You can even create your own maps within that directory. Made a mistake and the maps don't work? Well, simply delete them and the original ones will be back, as they are stored within the .PND.

Easy.

So, of COURSE we need multiple directories. It's not like on the GP2X or WIZ. You don't EXTRACT PNDs. You simply COPY them onto the card and run them (you could compare it to placing ZIP-files on the WIZ or GP2X without extracting them).
But as config files (and datafiles for games like Quake) need to be put somewhere, they are being put into a subdirectory in the appdata folder. With a name so you know where you can find it.
The user doesn't even have to create the subdirectories - they will be created when you run a game. So as long as you don't need any special game data (which should be the case for 99% of all games), you don't have to do anything except for copying that PND file onto your SD Card.
And for emulators... well, it's up to the emulator dev where he allows your rom path. Most of them allow any path on the SD, so you don't need to use the appdata dir for that. But the emulator will save its config there.

The config or datafiles should NOT be put into the PND. If anything goes wrong, you'd need to redownload the PND. Here all you need to do is simply remove the folder in the appdata directory and restart the game. It couldn't be more simple.


So simply said, the directory structure is the following:

/pandora/menu/SuperTux.pnd
/pandora/menu/Quake.pnd
/pandora/desktop/SuperMarioWar.pnd

Then there will be automatic data dirs:
/pandora/appdata/SuperTux
/pandora/appdata/Quake
/pandora/appdata/SuperMarioWar

For SuperTux and SuperMarioWar (which are complete games), you don't need to worry about anything. They simply save their config file there. Delete the directory to restore the default settings. That's it.
For Quake, you place the datafiles into /pandora/appdata/Quake/
That's it.

It's not so hard, is it?

If anyone has any better ideas how to handle it, let me know. We thought A LOT about it.
 
craigix said:
I also think the files should be in the same folder.

I hate the thought of this 'dll hell' of appdata.

What DLL hell? There are clean subdirectories for each PND you have on your card within the appdata directory.
You could even delete the whole appdata directory and the PNDs you have installed would simply run with their default settings and recreate their appdata/*-folder if they need to save anything there.

There are NO files directly in the appdata-directory. There are simply directories. One for each PND app that needs to save something.
 
Last edited:
EvilDragon said:
craigix said:
I also think the files should be in the same folder.

I hate the thought of this 'dll hell' of appdata.

What DLL hell? There are clean subdirectories for each PND you have on your card within the appdata directory.
You could even delete the whole appdata directory and the PNDs you have installed would simply run with their default settings and recreate their appdata/*-folder if they need to save anything there.

There are NO files directly in the appdata-directory. There are simply directories. One for each PND app that needs to save something.
And if a pnd never writes anything in its cwd there will be no appdata folder.
 
Last edited by a moderator:
B-ZaR said:
Dimacus said:
Personally I like the sound of having a separate folder for every pnd file, containing the pnd-file and a subfolder for it's external data.
It would make backing-up and deletion much easier and more intuitive for most new users.
This kinda walks on the toes of "just drag and drop the pnd". Maybe discovered pnd's could have these folders automatically generated? Then the pnd's could be automatically moved to these new folders. This way we could still have that drag'n'drop that's been touted everywhere :)

A subdirectory for a PND?
What sense would that make?
You'd like to have a single PND in a single folder?

If the user wants to sort his PNDs into subdirectories (i.e. name them "crap games" or "cool games") to sort and move his PNDs there, he could still do so.
libpnd crawls through those directories, it would discover them as well.

So you can sort them if you like or put them all into one directory.
Pretty clean thing.
 
Last edited:
foft said:
Good explanation. One more query - what is a .pnd? A tar.gz of binary, lib and pnd.xml file?

It's an ISO that can also be squashfs'ed.

So games like SuperTux only need 7MB instead of 16MB on the card (as they don't need to be unpacked).
Or AlephOne with all datafiles is 97MB big. Unpacked (like you run stuff on the GP2X or WIZ), it does take about 200MB.
 
Last edited:
EvilDragon said:
B-ZaR said:
Dimacus said:
Personally I like the sound of having a separate folder for every pnd file, containing the pnd-file and a subfolder for it's external data.
It would make backing-up and deletion much easier and more intuitive for most new users.
This kinda walks on the toes of "just drag and drop the pnd". Maybe discovered pnd's could have these folders automatically generated? Then the pnd's could be automatically moved to these new folders. This way we could still have that drag'n'drop that's been touted everywhere :)

A subdirectory for a PND?
What sense would that make?
You'd like to have a single PND in a single folder?

If the user wants to sort his PNDs into subdirectories (i.e. name them "crap games" or "cool games") to sort and move his PNDs there, he could still do so.
libpnd crawls through those directories, it would discover them as well.

So you can sort them if you like or put them all into one directory.
Pretty clean thing.

Hey, I've been arguing for the current implementation here, I just entertained the idea. His idea was to have all data, both pnd and the appdata under one subdirectory like so:
Code:
pandora/
pandora/apps/
pandora/apps/Quake/
pandora/apps/Quake/quake.pnd
pandora/apps/Quake/appdata/
pandora/apps/Quake/appdata/pak1.pak
pandora/apps/Supertux/
pandora/apps/Supertux/supertux.pnd
pandora/apps/Supertux/appdata/
pandora/apps/Supertux/appdata/customlevel.level   (or something)

So not just the pnd, but application-specific data directories too.

EDIT: emphasis on quote
 
Last edited by a moderator:
EvilDragon said:
foft said:
Good explanation. One more query - what is a .pnd? A tar.gz of binary, lib and pnd.xml file?

It's an ISO that can also be squashfs'ed.

So games like SuperTux only need 7MB instead of 16MB on the card (as they don't need to be unpacked).
Or AlephOne with all datafiles is 97MB big. Unpacked (like you run stuff on the GP2X or WIZ), it does take about 200MB.
What? Since when is squashfs supported?
OK, I see that it's supported in the Git now, but you can't use *both* ISO and squashfs; you have to choose one or the other.

Also, skeezix has told me that the whole PND system should be revised after the release of the Pandora (because of the problems PXML has etc); we'll see what happens.
 
Last edited by a moderator:
EvilDragon said:
[Talking sense]
I think that this system is perfect and dread the thought of it being hacked apart to appease some fears.

Having said that, though, DaveC is currently the only example we have of a Pandora-user-who's-not-way-into-its-software. The fact that this has confused him speaks to the way similar users will feel when they try to use the PND system. The obvious solution is education, essentially putting ED's post somewhere right before new users try to use PNDs. Or something to that effect, I'm really not certain what the best route for this information is. But still, great system, just needs education.
 
Last edited by a moderator:
B-ZaR said:
Hey, I've been arguing for the current implementation here, I just entertained the idea. His idea was to have all data, both pnd and the appdata under one subdirectory like so:
Code:
pandora/
pandora/apps/
pandora/apps/Quake/
pandora/apps/Quake/quake.pnd
pandora/apps/Quake/appdata/
pandora/apps/Quake/appdata/pak1.pak
pandora/apps/Supertux/
pandora/apps/Supertux/supertux.pnd
pandora/apps/Supertux/appdata/
pandora/apps/Supertux/appdata/customlevel.level   (or something)

So not just the pnd, but application-specific data directories too.

EDIT: emphasis on quote
That is what I was trying to say. With the above structure EVERYTHING related to an app can be in one subdir and not scattered into different directories in other spots. So everything Quake related would be in the Quake directory including PAKs and appdata. Want to delete or move Quake just drag the Quake folder to a new card or whatever and you are done. No need to hunt through a huge pile of directorectories which can be HUNDREDS of appdata folders in another spot to find PAKs etc. then go to a separate appdata folder make an appdata folder on the new card, move the quake appdata into the new folder appdata. It is just a waste of time and for nothing, it adds no benefit.


Another huge issue with this pnd thing is how apps are put into menus. They are put into the menus that the CODER wants them to be in. This takes the control out of the user's hands and puts it into the coders. So now you have YOUR system arranged how THEY want and not how YOU want it.

For example one coder wants Doom to show up in PORTS, the Wolf 3D coder wants it to be in SHOOTERS, the coder of Hexen wants it in GAMES, and the coder of Descent wants it is FPS.

Now you will have all of these games which are a similar genre scattered around in different menu spots. What if the USER wants all of these to go into a GAMES catagory in a menu? They can't do it. Now the user lost control of his own machine. I think this whole pnd idea is looking pretty bad honestly from a user's standpoint. I know the idea was to "dumb it down" so anyone could install an app but the user loses too much flexibility and control with this. I don't like that. I want my apps organized how I want not how someone else thinks they should be.
 
Last edited by a moderator:
The pxml is appended to the PND, right? So it can be edited without messing with the isofs? So could there be a simple tool to modify it so you can change the categories to fit your bill? It could maybe ask libpnd for all the PNDs currently discovered and allow editing their pxml data. No need to submit to the will of the packager :)
 
DaveC said:
Another huge issue with this pnd thing is how apps are put into menus. They are put into the menus that the CODER wants them to be in. This takes the control out of the user's hands and puts it into the coders. So now you have YOUR system arranged how THEY want and not how YOU want it.

For example one coder wants Doom to show up in PORTS, the Wolf 3D coder wants it to be in SHOOTERS, the coder of Hexen wants it in GAMES, and the coder of Descent wants it is FPS.

Now you will have all of these games which are a similar genre scattered around in different menu spots. What if the USER wants all of these to go into a GAMES catagory in a menu? They can't do it. Now the user lost control of his own machine. I think this whole pnd idea is looking pretty bad honestly from a user's standpoint. I know the idea was to "dumb it down" so anyone could install an app but the user loses too much flexibility and control with this. I don't like that. I want my apps organized how I want not how someone else thinks they should be.

THIS IS SIMPLY NOT TRUE

You have no idea how many years of work has been put behind the issue you're now bringing up.

Please, read the following page: http://standards.freedesktop.org/menu-spec/latest/apa.html
An application can be put in one or many toplevel categories, and one or many subcategories. It's one of the few standards in the Linux world that is actually being followed.
 
Last edited by a moderator:
I see PND's like cartridges, CD's, DVD's for games, it's not where the user data is stored.

If it is confusing, i.e. want to back up your settings, configuration for a game, then maybe we need to have a simple app that deals with backing up/moving/copying these stuff, nice and simple. This could even be integrated into the launchers (ran from there). And yes I'm aware DaveC says he doesn't like a separate app.

See it as being more like a console than a Linux machine where you can use the terminal or filemanager. In this regards it could actually end up being really nice simple.

Edit:
The only thing that may or may not be an issue is say the pak files, or files that can't be shipped with the game and are big that you wouldn't want installed on the nand
 
DaveC said:
Another huge issue with this pnd thing is how apps are put into menus. They are put into the menus that the CODER wants them to be in. This takes the control out of the user's hands and puts it into the coders. So now you have YOUR system arranged how THEY want and not how YOU want it.
There is a option in libpnd which allows you to have a config to override parts of the stuff defined in the pxml - so you can change the menu place if you really have to...

Also i don't get why you are asking all those questions again - we had exactly the same discussion back in 2008 when the pnd system was invented.
 
Last edited by a moderator:
DaveC said:
B-ZaR said:
Hey, I've been arguing for the current implementation here, I just entertained the idea. His idea was to have all data, both pnd and the appdata under one subdirectory like so:
Code:
pandora/
pandora/apps/
pandora/apps/Quake/
pandora/apps/Quake/quake.pnd
pandora/apps/Quake/appdata/
pandora/apps/Quake/appdata/pak1.pak
pandora/apps/Supertux/
pandora/apps/Supertux/supertux.pnd
pandora/apps/Supertux/appdata/
pandora/apps/Supertux/appdata/customlevel.level   (or something)

So not just the pnd, but application-specific data directories too.

EDIT: emphasis on quote
That is what I was trying to say. With the above structure EVERYTHING related to an app can be in one subdir and not scattered into different directories in other spots. So everything Quake related would be in the Quake directory including PAKs and appdata. Want to delete or move Quake just drag the Quake folder to a new card or whatever and you are done. No need to hunt through a huge pile of directorectories which can be HUNDREDS of appdata folders in another spot to find PAKs etc. then go to a separate appdata folder make an appdata folder on the new card, move the quake appdata into the new folder appdata. It is just a waste of time and for nothing, it adds no benefit.

Well, this is exactly what I don't want.
If my SD card is full and I want to temporarily remove stuff, I open up the directory with all the apps in there, mark all PNDs I don't like and delete them.
Done. My settings, saves, configs (don't need much space) stay there.
Easy.

With a directory structure like above, I'd have to go into each subdir to find out how big the PND is, delete it manually, etc.
This takes WAY longer.

BTW: you can define your folders in a config file.
If you want the subdirs within the same folder as the PNDs, simply change the config file and you're set.

Another huge issue with this pnd thing is how apps are put into menus. They are put into the menus that the CODER wants them to be in. This takes the control out of the user's hands and puts it into the coders. So now you have YOUR system arranged how THEY want and not how YOU want it.

For example one coder wants Doom to show up in PORTS, the Wolf 3D coder wants it to be in SHOOTERS, the coder of Hexen wants it in GAMES, and the coder of Descent wants it is FPS.

Now you will have all of these games which are a similar genre scattered around in different menu spots. What if the USER wants all of these to go into a GAMES catagory in a menu? They can't do it. Now the user lost control of his own machine. I think this whole pnd idea is looking pretty bad honestly from a user's standpoint. I know the idea was to "dumb it down" so anyone could install an app but the user loses too much flexibility and control with this. I don't like that. I want my apps organized how I want not how someone else thinks they should be.

Nobody takes your control. The devs just define the default category.
Don't like it? Then ORGANIZE them as you want :)
We have included an override function for PXML. Don't like the category? Well, you can simply override it (someone could code a menu editor where you can simply move your PNDs around with drag and drop and it will change the categories to where you want them).
Those overrides will be saved, so if you remove the PND and put it back later on the card, it will still use the category YOU decided.

Such tool to change the categories and move the files around as you like is not yet coded - we'd rather have a working OS first than adding all the features that could be needed.
The base structure is set - all that's left is the little tool and you can move them whereever you like.

And if you don't want to use the PND system - nobody forces you to use the menu. You can also manually place the PNDs whereever you like on your card, open up your file manager and doubleclick them to start.
Like on the GP2X. Just that you don't start a .gpe, but a .pnd.


But that is one thing that pissed me off the most on my GP2X:
I once had a broken card so I had to re-setup everything again. So I downloaded 100 games, extracted them (they all were zipped up differently), put them into various folders and subfolders... and if I were using gmenu2x, I also had to manually put them into the categories myself.
This did take hours, and as I wasn't in the mood doing that, I didn't use my GP2X much after that anymore.

With the PND system, this is easy:
Download them, put them on the card and that's it.

If you want, you can keep a copy of the config files (and PXML overrides) on your PC, as it doesn't take much space.
Then when you lose everything on the card, simply put the PND files back, put your backup of the config files back, and it's exactly sorted the way you did it.
 
Last edited:
Back
Top