Pandora Directory Structure Question


Actually on windows (recent ones) you cannot update data in the program folder .. They're finally trying toenforce multiusr and thus homedir.. App needs privilege escalation to update itself and so on

so generally most windows apps are install dir, homedir, and registry at minimum if they're to spec.

Jeff

xp doesn't do this, vista and win7 varies by policy settings iirc
 
skeezix said:
Actually on windows (recent ones) you cannot update data in the program folder .. They're finally trying toenforce multiusr and thus homedir.. App needs privilege escalation to update itself and so on

so generally most windows apps are install dir, homedir, and registry at minimum if they're to spec.

Jeff

xp doesn't do this, vista and win7 varies by policy settings iirc
Yeah, most people don't realize this, thanks skeezix.

What Windows does is actually kinda cool, since it's very similar to what the PND system does: any writes to the application directory (e.g. "C:\Program Files\Ubersoft\1337ware\") are automatically directed to "C:\Users\User\AppData\Ubersoft\1337ware" or similar. So I don't get why some guys around here are complaining.
 
Last edited by a moderator:
Stuff that needs large external data is a slightly different thing to write space for config files, and I would suggest an alternative:

You put the data and PND file each where you like.
The app asks you where it is on first run. (Or maybe even scans automatically)
It saves that info to a config in it's /appdata directory. (It could just prompt again if it moved)

You can arrange the PND and data where you like on the card however you like.

I think EvilDragon is right that most of the time you don't want to delete your settings (or at least don't need to).
However, if large data files were in the /appdata directory, it would mean that it was actually necessary to go into it to free up the space.
 
If I am understanding this correctly, appdata serves essentially the same purpose as the .config and various .appname directories in /Home/Username. If this understanding is correct, I have no complaints especially if a separate /appdata/appname directory is created for each PND that requires such configuration files. I would also assume that Save As and Open dialogs would exist to allow user defined organization for documents, images, media files, roms, etc.
 
EvilDragon said:
MDave said:
There are good and bad points to both types of implementations that are argued for.
DaveC wants what has worked for years on Windows in terms of ease of use and knowing where everything is related to the app, one folder named after the app with all its contents in there.
EvilDragon wants something that works good if you have lots of folders and would like to remove config and other data without touching the actual apps.
I see EvilDragon's specific scenario not something that common. If you do a lot of formatting and installing apps over and over then yeah, I see the plus side to this.
But that isn't going to happen on the Pandora for your average Joe that just wants to play games and not mess with Linux distros on it, are they?
In that case, I'm in favour of what DaveC is talking about. It's worked great for PSP homebrew users, and more recently Wii homebrew users too.

Oh, it doesn't work for Windows. Most Windows apps (and most Linux apps) do write their config settings either into the Home-Directory, the Local Settings or the Registry.
Most average Joe users don't know this, but it happens. If you delete the directory, you have the config files left.

Also... ermm..
The PND System is even easier for the average Joe user.

Compare:
To install a game on the Wii or PSP, you have to download it, extract it into specific folders onto your SD Card.
To install a game on the Pandora, you have to download it and place it into a specific folder onto your SD Card. It's the same, except for missing that extra "extract it"-Step.

To remove a game on the Wii or PSP, delete the whole folder. If you don't want to lose your settings / saves, etc. , you have to manually fiddle in the folder to find out your settings / saves / etc. files.
To remove a game on the PND, delete the .PND. You won't lose your settings. You want to delete the settings as well? Okay, simply delete ONE more folder.

To install a game like Quake on the Wii or PSP, you have to download it, extract it into specific folders onto your SD Card. Then you grab the Quake data files and place them into a directory as well.
To install a game like Quake on the Pandora, you download it, put the PND file into a specific folder. Then you grab the Quake data file and place it in the Quake-Subdirectory.

As PNDs can be compressed, they need much less space than uncompressed files. Loading is also faster for games that have many small files.
Putting games on the card is also faster. I remember a game on the GP2X that took approx. 2 hours to put on my SD Card as it had so many small files. When it was packaged up in a filesystem, it needed 5 minutes.

So... ermm... it's faster, smaller, is as easy to handle as the normal "put stuff into a directory".
But it's also more convenient.


you got a point, but I think that (des)installing/updating a wii homebrew is easier even than using pnd... for the average joe you mention. I mean... they simply use the "homebrew browser" and it makes the whole instalation/desinstalation/update process for them without any knowledge on the content of the SD card for the user (appart for the first instalation of the homebrew channel and the setting of the homebrew browser that is...)


edit: nothing prevent the pandora to have some kind of "homebrew browser" too...
 
Last edited by a moderator:
Okay layman's take on it here I just want to see if I understand this.

Say there's dozens of "apps" I want to try out on the "store".
I D/L them to my SD, slap that in the Pandora, hit the PND and it loads up.
No issues there. It just works and I like that. Yeah, it's totally like a cartridge. Retro baby.

Lets say I dont like an "app" and I delete it...
-keep in mind that with the near limitless number of new Linux programs we're likely to see every day, as consumers this is something that's likely to happen often especially with new versions coming and going to revise it to work better over time.
This means as an average 'plug and play' consumer unless I'm reminded to get rid of "app data" folders after deleting each PND there's going to be a point where I go in there and find 20 folders for apps I may never use again. But assuming I'm used to it, it's two deletions we have to do. Which would be akin to later CD based systems that had battery back up for on board game saves.

Lets say I like a ton of "apps" I fill up a 8gb card and need to move stuff off to transfer to a new SD. Chances are all I'm going to do is plug my SD into a PC or card reader, then drag and drop everything into a holding folder, get a new card and drag everything back. Appdata folders and PNDs all come a long for the ride. Simple.

Then we have Emulators and stuff like Beats of Rage.
We'll have an emulator PND and a folder for all our ROMs and ISOs and BORpacks I assume(?) and settings for each parent saved in the appdata folder for each. But what about each rom will those have their own data folder or will they all default to the folder of the program running it? (I'd assume the latter).

I dont pose these scenarios to call any of the file system into question just as someone trying to understand the file system.
 
Elwing said:
you got a point, but I think that (des)installing/updating a wii homebrew is easier even than using pnd... for the average joe you mention. I mean... they simply use the "homebrew browser" and it makes the whole instalation/desinstalation/update process for them without any knowledge on the content of the SD card for the user (appart for the first instalation of the homebrew channel and the setting of the homebrew browser that is...)
edit: nothing prevent the pandora to have some kind of "homebrew browser" too...

Ermm, yeah, exactly. That's one argument that's a bit dumb :)
The homebrew browser is an app which handles the deletion of all those games. Who says the Pandora won't have such an app? ;)
It's not that it's really hard to code or so...

But! There is going to be emulators that require the user to place bios files somewhere. Maybe the emulator is kind enough to let you search for it through a sort of file explorer, but all the ones I've used require them to be in a folder called bios in the apps folder. All the Quake, Doom and other commercial game ports are also going to require the user to put their legally owned game data into the app folders too, so it's not going to be all easy for those that don't know about the ins and outs of how the system works.

So... you actually think it's much more complicated searching and copying a bios and some data files inside a directory named /pandora/appdata/Quake1 than copying the same fils into a directory named /pandora/menu/Quake1 ...?
 
Last edited:
Alpha2 said:
This means as an average 'plug and play' consumer unless I'm reminded to get rid of "app data" folders after deleting each PND there's going to be a point where I go in there and find 20 folders for apps I may never use again. But assuming I'm used to it, it's two deletions we have to do. Which would be akin to later CD based systems that had battery back up for on board game saves.
Does it really matter to the plug'n'play consumer if they have dozens of config folders in a directory they never use?
The only time they would notice, is when they reinstall an app and don't need to reconfigure anything.

I'd actually suggest making the appdata/ folder .appdata/ by default (with an easy way to access it for power users).
I think apps should be designed so that the user should never have to go into that folder for normal usage, and making it a hidden folder would help to remind developers of that.
This includes things like Quake; I don't think it's a good idea to require the user to place the data files in a specific, not necessarily obvious place.
Most people have agreed, you should be able to put ROMs for emulators wherever you like, why should Quake be any different?
 
Last edited by a moderator:
It's a pretty different design paradigm, though. An emulator is made to be a program that opens other files, just like a word processor or the like. But Quake does not include easy "select the interlinked game files you wish to open" functionality.
 
EvilDragon said:
But! There is going to be emulators that require the user to place bios files somewhere. Maybe the emulator is kind enough to let you search for it through a sort of file explorer, but all the ones I've used require them to be in a folder called bios in the apps folder. All the Quake, Doom and other commercial game ports are also going to require the user to put their legally owned game data into the app folders too, so it's not going to be all easy for those that don't know about the ins and outs of how the system works.

So... you actually think it's much more complicated searching and copying a bios and some data files inside a directory named /pandora/appdata/Quake1 than copying the same fils into a directory named /pandora/menu/Quake1 ...?

No, that is not exactly what I'm actually talking about :) Look at it from the perspective of a new user with no or very limited technical skills (say someone got a Pandora for their kid).

Or even a user that does have some reasonable level of technical ability that doesn't know how the folder structure works.

Joe downloads Quake from the appstore, and it installs the PND onto the SD card invisibly to the user. They don't know where it's stored on the card, or that it's even there.

Joe see's the PND show up on the desktop (thanks to the great auto-discover daemon you guys coded in!).

Joe tries to run it. It gets an error about missing pak files (because it's not legal to include shareware or full game files in the PND from appstore).

Joe thinks it's a faulty download or game, and leaves it.

Maybe Joe knows to look around the SD card, and finds the Quake PND in the Pandora folder. Because the game didn't load, did it manage to create the /pandora/appdata/Quake1 directory?

Anyway, lets say he figures out he needs to put the pak files somewhere. If the /pandora/appdata/Quake1 folder doesn't exist yet, and he finds the /pandora/menu/Quake1 folder, he's going to assume you put the pak files there, right?

He does, and it still doesn't work. Wouldn't you get confused and annoyed at this point? :p

However, this is going to only happen for apps like these (like commercial game ports or some emulators) but due to their popularity, a LOT of people who don't know this system are going to go through this process.

One good way of alleviating the problem is including instructions on how to install the game data in the appstore, before they click the download button :p but as we all know, most people will skip things like that and just want to go straight to downloading it. Or they forget about the instructions after the downloaded and closed the appstore :p
 
Last edited by a moderator:
Guys this is not that hard to solve.
Make a shell script that is the exe in the PND rather than Quake.
- check current directory for PAK files.
if none exist
- prompt user for location of PAK files and a nice explanation of why they're not included
else
- launch quake

Easy peasy.


Also there's not GOING to be a pandora/menu/Quake1 folder, it's a PND file... wtf?
 
Kicker said:
It's a pretty different design paradigm, though. An emulator is made to be a program that opens other files, just like a word processor or the like. But Quake does not include easy "select the interlinked game files you wish to open" functionality.
Perhaps, but it's different again from the problem the appdata directory was designed to solve: Write space for otherwise static apps.

From a purely technical point of view, the data files should be inside the PND, but obviously that's not an option.
I feel that saying "oh well put it in appdata/ then" isn't really the right solution.

Which is why I suggested a wrapper that only asks on first load (and if the file is missing later), and stores the path in a config file.
 
Last edited by a moderator:
I'm suddenly reminded of those cute Guinness commercials.

"Brilliant!" "Brilliant!"
 
rabidpoobear said:
Also there's not GOING to be a pandora/menu/Quake1 folder, it's a PND file... wtf?

You can put and run the PND file anywhere you want, but if you want the PND to show up on the desktop or menu, then you put it in either the pandora/desktop/ or pandora/menu/ folder.

Pretty sure that's how it works, right?
 
Last edited by a moderator:
MDave said:
You can put and run the PND file anywhere you want, but if you want the PND to show up on the desktop or menu, then you put it in either the pandora/desktop/ or pandora/menu/ folder.

Pretty sure that's how it works, right?
Yes, but that means you have a /pandora/menu/Quake1.pnd file, not a separate directory.
 
Last edited by a moderator:
Aninhumer said:
Alpha2 said:
This means as an average 'plug and play' consumer unless I'm reminded to get rid of "app data" folders after deleting each PND there's going to be a point where I go in there and find 20 folders for apps I may never use again. But assuming I'm used to it, it's two deletions we have to do. Which would be akin to later CD based systems that had battery back up for on board game saves.
Does it really matter to the plug'n'play consumer if they have dozens of config folders in a directory they never use?
The only time they would notice, is when they reinstall an app and don't need to reconfigure anything.

I'm talking about stuff you wont reinstall again. All that junk will build up over time. It's annoying enough when you have to go into the program files folder on a PC and get rid of 2 dozen folders for programs you haven't used in 2 years that werent removed by uninstalling. I'm just hopping to keep my SD card as clean as possible from the start, not big on wasting space when I like to fill as much space as I can.

And again I'm just trying to understand how it's set up because not understanding could lead to a mistake later on, no matter how simple you make it there's always a risk.
 
Last edited by a moderator:
There are a few things about this pnd thing that are bothersome.

Yes, one of them is that it forces you to have files scattered into separate places. I like stuff more self contained, everything for the app, data files BIOS etc in it's own folder somewhere. How many times have I deleted just the executable but left config files on the card to save space on other systems like Wiz? 0. If I need to save space I just moved the whole folder (now with the pnd system I will have to mess with TWO folders) off of the card to my PC rather than leave some junk on the card, that is sloppy. If you REALLY have so much trouble with card space that you are doing this so much that it is an issue, my suggestion, buy a bigger SD card :rolleyes:

The other issue is that many minimal launchers etc will detect and put the game into a catagory that the coder decided as it is imbedded in the pnd and even worse it may show up in multiple places (slop).

Another issue is that you will be stuck with the icon that is embedded in the PND. It probably won't match if you are using a minimal launcher, and coders aren't known many times for their artist abilities. Users will want to make or load icons into their system to match the skin they are using.

There is too much "automagic" going on here that keeps users from customising their system how THEY want.

There could be an easy solution. Have the PND do a check on load for a .ini file of the same name in the same dir as the app. AppX.pnd will look for AppX.ini. If it doesn't find an .ini file then it will just use the defaults like now. So ED you would not have an .ini for your apps if you don't like it(I assume because you only want one file)and it will just do as now. When the pnd DOES find an .ini file it will use the parameters to override the defaults. With this override you can set it to load the icon you want, the catagory the app will show in and the directory path you like for appdata.

So you would have two possibilities:

Just the pnd file like now plus stuff defaulted to the appdata dir like now.

If there is an appname.ini file in the same dir (because the user put one there) as the pnd, it will detect and use the parameters in that file to override all defaults.

This way joe blow that doesn't care just places the pnd on his system and the pnd automagically makes an icon for him and he is oblivious to the appdata dir it made on his card. He doesn't know or care. Now when power user comes along and wants his own icon, wants the app to show in a certain menu catagory, and wants appdata in a spot he wants he can just make an .ini file in with his pnd and now regains control of his system.
 
We've stated many times.. the system has a built in option for overrides; you can override the developer set category, right at the pnd-level; presumably the menus will have that option coded for them, or someone will code up a override editor tool. But the pnd-system has overrides built in .. so if the dev says 'default to category Games', but you want it in "Applications", you can do that. The goal is.. we might just save you the hastle, it has a good chance of just being right. You want to move it, shoudl be a piece of cake. (maybe not day one, but the system is there, so day 3 maybe :)

Likewise for icons; presumably menus will let you override the icon in some way or another, or do it at the pnd level. OR worst case, use a pnd-editor and just slap a new icon on it (ED is working on just such a tool.)

We have gone out of our way to make 'automatic, but not forcing you'; seems to me you're making an issue out of somethign that its not -- ie: you had to do all these things _before_ -- developer included an icon foo.png; how many peopel _Really_ edittedf that icon and replaced it? So you can do the same thing now, its just that instead of having a separate file, its built in.. that is _better_. The menu could still allow an file with the same name tobe shown as a replacement icon.. who said the menu authors couldn't? So whatg we have is better.

Nothing is lost over what you had before.. we've just added sensible defaults in a single package :)

So your 'easy solution'.. yes, thats there, menu authors can do it; and at the pnd-level (PXML level), thats built in too, but rather than have peopel futzing with PXML.xml, we want someont to write a tool for that (be it in the menu, or a standalone tool), which will come.

See, I thought of that ;)

This has come up about 5 times; people will keep bringig it up, but it pains me every time.. we beat it to death, and same output :)

jeff
 
Back
Top