Ok I Tried The Whole Separate Appdata Dir Thing

[Exophase]

I have some tangentially related questions on things I guess were not clear to me and are still not clear after reading the Wiki. I don't want to derail this thread much with answering my questions, but I feel like I have to have a better concept of operation before I can form a good opinion on the topic at hand.

I'm going to use Temper as an example since it's the first thing I'll be porting on Pandora, but any other emulator I do will probably be similar.

The Temper distributions right now come in a zip file that contains a binary and a readme. First question: is it conventional to have the readme for an application as a part of a PND, and expect the user to read it on the Pandora itself? Or are apps zipping up PNDs with readmes? Is there a major user preference here? I usually read readmes on a computer, not on the thing I'm installing it on, but people will probably be downloading PNDs directly to their Pandoras a lot of the time. I'm sure PXML has something for pulling documentation out of the PND and putting it in the right place anyway, but for those who want to read it on a computer anyway should I include the readme outside of the PND too?

Now, Temper doesn't have any other data files that come with it, but has a placeholder directory for syscards (BIOS files in more common parlance). At runtime it will create a bunch of directories for files it'll later generate (game-specific config files, savestates, screenshots, etc). We're told libpnd and the OS abstract access to the files within the PND and created by the binary. So what specifically is happening - is the PND mounted somewhere as read-only, then the binary is loaded with the mount location set as the pwd? Then the directory is also merged with the PND's appdata directory? So when I want to make a new file I just do it in . like I am now? Or do I need to use libpnd to get paths or open files?

So for that syscards directory, should I not be including it in the PND since the user will actually have to add syscards to /pandora/appdata/temper/syscards (also making the directory)? There could be benefit to including them in the PND as well, since they're not files you'd change much, but obviously I can't package them with the PND myself. So if a user places it in syscards in the PND will that get merged with the appdata syscards, when I'm reading from .? Or will it pick one? Or am I way off and the app really does have to specifically access the PND directory and the appdata directory separately?

And for ROM browsing, should I default initially at ., which I'm still assuming will be at a merged PND mount + appdata? It makes much more sense NOT to do that, but let's say I do - where would the user .. to?

I guess my questions can mainly be boiled down to, specifically what directory structure is being abstracted by the appdata and PND and what are preferred conventions for where things should be stored.

 

[Trip]

The argument would go away if we clled it /pandora/home instead of /pandora/appdata

jeff

:lol: I bet it would. Either that or call it My Documents

 

[skeezix]

On documentation,

A pnd file should have documentation in it if appropriate (see my 'good form' hints here: http://pandorawiki.org/Libpnd_hub#Recommended_layout_of_a_pnd_directory_structure.2C_ie:_how_to_make_a_well_behaved_pnd_file)

ie: if an app is so utterly obvious it needs no docs, dont' add them (avoiding cluttering the user document menu), but for any non-trivial app, I think it good form to include documentation. The PXML.xml can point to a single file (text or html), and the system (pndnotifyd) will spit out a .desktop that shows in the Documentation menu. (minimenu lets you hit 'Y' while selecting an item, to bring up documentation instead.) The browser is used to show the documentation, and it of course is while the pnd is mounted, so may branch into other files. (ie: example -- you might juyst have a readme in the pnd, or maybe you've put the entire dosbox documentation in there, up to you.)

So a pnd-file on the appstore or dl.openhandhelds should be complete unto itself, including built in documentation.

A _zip_ for download from some random place (or dl.openhanmdhelds perhaps) could wel have addition README in it; the "app store" itself should generally be serving out pnd files, instead of zips, for ease of use right on the pandora itself (hence the size and design of the 'app store')

On files/dirs,

No special work is neededf from the developer, beyond it being good form to use CWD (current workign dir) as the base point (ie: instead of user homedir as is common on unix apps.) ie: if you do 'mkdir foo', then "foo/" will be created just like anywhere else. Yes, the pnd is mounted into the filesystem (where is not relevent), and a union filesystem (aufs in our case) is used, so that any writebacks get insteadf sent to the SD appdata directory for your app (say, /pandora/appdata/temper, for example.) The way a unionfs works is that any file found in the alt locations but not in the source, is used; if the file in the alt location is in the source as well, the newer file is used. When writing to the union, the alt location is used. Voila, piece of cake Your app need not be libpnd aware whatsoever, unless it wants to use libpnd apis (handy IO bits for instance, or running pnd-files, etc.)

Its piece of cake awesomeness.

On included data,

If your runscript/binary create the directories, they're good to go. You can also use (a frowned upon) trick in PXML.xml to request pndnotifyd to auto-create directories as soon as the card is inserted; generally not a good idea but I built it in as a convenience swhoudl it be needed (And this behaviour can be turned off by the user if its over-used and invasive.)

But in theory .. first time the user runs the app, the appdata dir will be created, and your runscript (say) will create any directories or data files needed/etc. Emu says 'wait, no BIOS or roms, put your stuff in /foo and lets quit'; user can do so. My 'good form' guidelines suggest including a rom directory browswer, so the user can put his ROMs anywhere on his cards (since he has a built in NAND, plus his two SD cards, and possibly usb drives etc .. from app perspective, just let them cruise around, so they can navbigate to /media/usb123 if they want to.) So your only confusing one is BIOS realy, and if you want it in a well defined location, just assume "./bios" say, and put "mkdir bios" in your runscript/binary, so that after firs trun the directory structure is all there in /pandora/appdata/temper and nice and obviosu for the user. (Feel free to also copy over or geneate textfiles.. ie: you coudl put in your .iso part of the pnd a directory called "template" say, and then in your runscript, do "mkdir bios; cp template/readme.txt ./bios", so after first run the /pandora/appdata/temper/bios dir would be made, and get your readme.txt put into it, to help clue the users in.

On default dir,

I currently default to "." for dir browser, in case the user has put roms there (or ./roms, say.) I keep track of last used rom dir, so if the user navigate to /media/mmcblk1p1 (their SD2 say), it'll rememebr that.. maybe they keep emus on SD1, and all their ROMs on SD2.

I am tempted to default to the root of the 'current SD' (the SD the app was run from), but that might be confusing. *Shrug*

--

Let me know if my "Well bahaved" link in the wiki does not cover some of the above, or the other parts of libpnd hub; I can write new bits if needed, I just don't know where the holes are offhand. (Nor do I know if a single person has evber read that stuff

jeff

 

[dflemstr]

The Temper distributions right now come in a zip file that contains a binary and a readme. First question: is it conventional to have the readme for an application as a part of a PND, and expect the user to read it on the Pandora itself? Or are apps zipping up PNDs with readmes? Is there a major user preference here? I usually read readmes on a computer, not on the thing I'm installing it on, but people will probably be downloading PNDs directly to their Pandoras a lot of the time. I'm sure PXML has something for pulling documentation out of the PND and putting it in the right place anyway, but for those who want to read it on a computer anyway should I include the readme outside of the PND too?

Do both! The PXML has a tag for linking to documentation files (See the info element) that accepts files of type text/plain or text/html, so you should definitely use that to create documentation *inside* of the PND. But nothing prevents you from copying those to outside of the PND as well; please keep in mind, though, that it's uncommon to distribute ZIP files for applications; most people just upload the plain PND file as-is, so there's no possibility for you to add external documentation in that case.

(PS: The info element supports URLs of any kind in practice (http, etc), even if the spec doesn't say so explicitly, so you can host your documentation on a web site as a hybrid alternative)

Now, Temper doesn't have any other data files that come with it, but has a placeholder directory for syscards (BIOS files in more common parlance). At runtime it will create a bunch of directories for files it'll later generate (game-specific config files, savestates, screenshots, etc). We're told libpnd and the OS abstract access to the files within the PND and created by the binary. So what specifically is happening - is the PND mounted somewhere as read-only, then the binary is loaded with the mount location set as the pwd? Then the directory is also merged with the PND's appdata directory? So when I want to make a new file I just do it in . like I am now? Or do I need to use libpnd to get paths or open files?

The system uses aufs to create a writable overlay over the PND mount point, so yes, you just write to CWD. If you want to create special folders outside of your appdata directory, there's also the "<mkdir>" element; I discourage its use, however, since it's implemented very hackishly.

So for that syscards directory, should I not be including it in the PND since the user will actually have to add syscards to /pandora/appdata/temper/syscards (also making the directory)? There could be benefit to including them in the PND as well, since they're not files you'd change much, but obviously I can't package them with the PND myself. So if a user places it in syscards in the PND will that get merged with the appdata syscards, when I'm reading from .? Or will it pick one? Or am I way off and the app really does have to specifically access the PND directory and the appdata directory separately?

As a BTW: The appdata will only contain files that are written to the PND mount point. The PND's contents won't appear in the appdata directory. But yes, the directories inside of the PND and in the appdata folder are merged recursively from the applications POV, and appdata contents override PND contents if there are conflicts.

And for ROM browsing, should I default initially at ., which I'm still assuming will be at a merged PND mount + appdata? It makes much more sense NOT to do that, but let's say I do - where would the user .. to?

The user would ".." to the mount point super directory, aka not "...sd/pandora/appdata", but instead somewhere around "/mnt/..." (I can't tell for sure because I don't own a Pandora yet). So don't use the policy that the user should store ROMs in an appdata folder (or "."); it's a very user-unfriendly location to store stuff in in general.

I guess my questions can mainly be boiled down to, specifically what directory structure is being abstracted by the appdata and PND and what are preferred conventions for where things should be stored.

• The PND is mounted under some mount point, e.g. "/mnt/foo"
• An appdata directory is created at e.g. "sd/pandora/appdata/foo"
• An union mount is performed on "/mnt/foo" and "sd/pandora/appdata/foo", putting the appdata directory 'on top' meaning that that's where all writes go. The location of this union is either overlain over the PND mount point or put somewhere completely different (can't remember which, but it shouldn't matter, because the folder's contents will be the same in any case, as will the writes by your app).
• The PND launcher cd's to the overlay directory and invokes the application as indicated by the "<exec>" element in your PXML file.

 

[Trip]

And for ROM browsing, should I default initially at ., which I'm still assuming will be at a merged PND mount + appdata? It makes much more sense NOT to do that, but let's say I do - where would the user .. to?

The user would ".." to the mount point super directory, aka not "...sd/pandora/appdata", but instead somewhere around "/mnt/..." (I can't tell for sure because I don't own a Pandora yet). So don't use the policy that the user should store ROMs in an appdata folder (or "."); it's a very user-unfriendly location to store stuff in in general.

People will most likely store their ROMS in a folder near to the root of the sd card (e.g /mnt/sd1/roms). This is because there will be multiple emulators for some of the systems and this will make them easier to find.
Pointing towards the root of the SD card as default will probably be a good idea

 

[Zeno Arrow]

Zeno -- thats how it is, but not version; thats not his problem though (and if you did it by version, it would mean every time you upgrade the app, you lose your data

Presumably most apps are okay with version upgrades, so UAE4ALL will have a UAE4ALL appdata dir (its a name chosen by the developer, not some random number) for all of time .. so its great

Thanks for the reply skeezix, you make a good point about version upgrades, but surely it is necessary to separate config files out by version number? Imagine you had two versions of UAE4ALL on your Pandora, the older one supported a maximum refresh rate of 50Hz, the other supported a maximum refresh rate of 60Hz. If you set the refresh rate to 60Hz in the newer version, when you ran the older version the setting is no longer valid.

What I think is needed to get around the issue is to keep the configs separate but have an 'import settings' mechanism, so that newer versions copy over the settings that are useful, and use the app defaults for unused/new settings.

The way I'd see it working is like this. PXML has details of config defaults. When you run a PND for the first time, it looks for appdata for your version number and doesn't find it. It then looks for configs for older versions (if it had multiple options, it would pick the newest). Pop up dialog box asks whether wish to import settings from this version or use defaults. User makes choice, and config for this new version is created in appdata folder. If old version doesn't have a setting that the new version does, the default value defined in the PXML is used.

Wouldn't that solve it?

DaveC and some others quite rationally want the appdata dir to be in the same place as the application.pnd file -- ie: some in /pandora/menu and some in /pandora/desktop; mor eto point, DaveC wants to put his apps in /pandora/menu/hatari (say, for hatari), so it would look like /pandora/menu/hatari/hatari.pnd and /pandora/menu/mame/mame.pnd for example. IT already supports this... but DaveC wants it so the appdata woudl then be /pandora/menu/hatari/hatariappdata/ so that inside his /pandora/menu/hatari directory is the hatari.pnd and the hatari appdata diredctory and other hatari stuff.

The thing is, I don't think this will solve the mess either. Imagine upgrading the version of Hatari you want to use. There might be a case where a new version has a bug with a game that an older version doesn't, so you want to keep both on your system. So you copy the PND of the new version of Hatari into where the old one is, and have both on your system, both using the same config file. As I mentioned with the UAE4ALL example, this isn't ideal as there might be legitimate reasons why you would want to have different configs for different versions of an app.

To me the issue is not whether you need multiple configs or not, but rather how those multiple configs are handled, and I think splitting out appdata by version number is the most sensible way to do that.

 

[mindlord]

The thing is, I don't think this will solve the mess either. Imagine upgrading the version of Hatari you want to use. There might be a case where a new version has a bug with a game that an older version doesn't, so you want to keep both on your system. So you copy the PND of the new version of Hatari into where the old one is, and have both on your system, both using the same config file. As I mentioned with the UAE4ALL example, this isn't ideal as there might be legitimate reasons why you would want to have different configs for different versions of an app.

To me the issue is not whether you need multiple configs, but rather how those multiple configs are handled, and I think splitting out appdata by version number is the most sensible way to do that.

This is why you can override certain aspects of the spec - simply override Hatari B to point to a different appdata folder.

 

[Zeno Arrow]

The thing is, I don't think this will solve the mess either. Imagine upgrading the version of Hatari you want to use. There might be a case where a new version has a bug with a game that an older version doesn't, so you want to keep both on your system. So you copy the PND of the new version of Hatari into where the old one is, and have both on your system, both using the same config file. As I mentioned with the UAE4ALL example, this isn't ideal as there might be legitimate reasons why you would want to have different configs for different versions of an app.

To me the issue is not whether you need multiple configs, but rather how those multiple configs are handled, and I think splitting out appdata by version number is the most sensible way to do that.

This is why you can override certain aspects of the spec - simply override Hatari B to point to a different appdata folder.

Yes, and it's important that you should be able to do this, but how do you handle creating this new appdata folder and creating the config files within?

Of course you could do it all by hand (i.e. make new folder, point app at new appdata folder, run app to create default config for app, tweak app settings to have them virtually the same as another version), but following what I suggested would make this so much easier, it would just be a case of running an app and choosing from a yes/no dialog box, and changing the one or two settings you wished to tweak for that version. Structure of appdata folders would be automatically laid out cleanly too.

 

[WizardStan]

To me the issue is not whether you need multiple configs, but rather how those multiple configs are handled, and I think splitting out appdata by version number is the most sensible way to do that.

If it becomes necessary to have two different versions of a given program with incompatible config files, you can always modify the PXML to use a different appdata directory. This seems like an edge use case to me though, I wouldn't expect you to need multiple different versions (an emulator or two, as you've suggested), and when you do, it seems unlikely that the config would have changed so drastically. Seems to me that attempting to enforce (or suggest) extra work for the developers that won't need the functionality is bad form, and it would be better to handle it at the application level. For example, instead of loading "settings.xml", maybe it attempts to load "settngs_vXYZ.xml" corresponding to its own version number and then the falls back to the default settings.xml, or any other number of solutions. Unless it can be made entirely transparent to the developer, we shouldn't have to follow some sort of multi-version paradigm on the off chance that someone wants to run different versions of our application.

 

[mindlord]

Yes, and it's important that you should be able to do this, but how do you handle creating this new appdata folder and creating the config files within?

Of course you could do it all by hand (i.e. make new folder, point app at new appdata folder, run app to create default config for app, tweak app settings to have them virtually the same as another version), but following what I suggested would make this so much easier, it would just be a case of running an app and choosing from a yes/no dialog box, and changing the one or two settings you wished to tweak for that version. Structure of appdata folders would be automatically laid out cleanly too.

When a PND is run it does a sanity check for it's appdata folder. If you've overridden the default appdata folder in the pxml.xml file it doesn't exist, yet. The PND would generate it's folders and configs just like you've run it for the first time. I think you're over thinking this.

 

[skeezix]

See this other thread for testing the mod for DAveC:

http://www.gp32x.de/board/index.php?/topic/54192-beta-brave-souls-come-help-test-appdata-in-same-place-as-pnd/

jeff

 

[Zeno Arrow]

To me the issue is not whether you need multiple configs, but rather how those multiple configs are handled, and I think splitting out appdata by version number is the most sensible way to do that.

If it becomes necessary to have two different versions of a given program with incompatible config files, you can always modify the PXML to use a different appdata directory. This seems like an edge use case to me though, I wouldn't expect you to need multiple different versions (an emulator or two, as you've suggested), and when you do, it seems unlikely that the config would have changed so drastically. Seems to me that attempting to enforce (or suggest) extra work for the developers that won't need the functionality is bad form, and it would be better to handle it at the application level. For example, instead of loading "settings.xml", maybe it attempts to load "settngs_vXYZ.xml" corresponding to its own version number and then the falls back to the default settings.xml, or any other number of solutions. Unless it can be made entirely transparent to the developer, we shouldn't have to follow some sort of multi-version paradigm on the off chance that someone wants to run different versions of our application.

I can definitely foresee people wanting multiple versions of emulators on their machines. For example, it is well known that earlier MAME versions are faster at running certain games than later versions (as the goal of the MAME project is to get as close to the original hardware as possible, and as you increase the simulation accuracy more often than not you're increasing the processing power needed too). So, for example, I might get better Mortal Kombat 2 performance with an older MAME, but I might want a newer MAME to play a game the older version doesn't support.

The problem with using one "settings.xml" file as a backup when "settngs_vXYZ.xml" isn't found is that it's not going to let you transfer your custom settings between emulator versions, it's just going to go back to the app defaults every time you upgrade.

The other thing is, you might have multiple configs for one version. If we agree it would be good to have an SD card cleaner script that gets rid of configs you no longer need (as the PND is no longer on the SD card) how does the script know which config files it should get rid of? If you have all the configs in one folder you make it much harder to figure out, whereas if you have configs split out by app version, you simply delete the app folder for the versions that are no longer present.

Another thing is that it would be the job of the OS to handle most of this, so it would be easy for the developers to follow. All they'd need to do would be to provide default settings for the app in the PXML (for the reasons I mentioned in an earlier post).

You could make it even easier to keep appdata folders clean by offering an option to run the SD card cleaner script whenever you ran a new version for the first time. So after creating a config for the new version, you then ask the user whether they would like to remove the config for the older version.

Does anyone agree with me on this?

 

[skeezix]

Zeno -- thats how it is, but not version; thats not his problem though (and if you did it by version, it would mean every time you upgrade the app, you lose your data

Presumably most apps are okay with version upgrades, so UAE4ALL will have a UAE4ALL appdata dir (its a name chosen by the developer, not some random number) for all of time .. so its great

Thanks for the reply skeezix, you make a good point about version upgrades, but surely it is necessary to separate config files out by version number? Imagine you had two versions of UAE4ALL on your Pandora, the older one supported a maximum refresh rate of 50Hz, the other supported a maximum refresh rate of 60Hz. If you set the refresh rate to 60Hz in the newer version, when you ran the older version the setting is no longer valid.

What I think is needed to get around the issue is to keep the configs separate but have an 'import settings' mechanism, so that newer versions copy over the settings that are useful, and use the app defaults for unused/new settings.

The way I'd see it working is like this. PXML has details of config defaults. When you run a PND for the first time, it looks for appdata for your version number and doesn't find it. It then looks for configs for older versions (if it had multiple options, it would pick the newest). Pop up dialog box asks whether wish to import settings from this version or use defaults. User makes choice, and config for this new version is created in appdata folder. If old version doesn't have a setting that the new version does, the default value defined in the PXML is used.

Wouldn't that solve it?

DaveC and some others quite rationally want the appdata dir to be in the same place as the application.pnd file -- ie: some in /pandora/menu and some in /pandora/desktop; mor eto point, DaveC wants to put his apps in /pandora/menu/hatari (say, for hatari), so it would look like /pandora/menu/hatari/hatari.pnd and /pandora/menu/mame/mame.pnd for example. IT already supports this... but DaveC wants it so the appdata woudl then be /pandora/menu/hatari/hatariappdata/ so that inside his /pandora/menu/hatari directory is the hatari.pnd and the hatari appdata diredctory and other hatari stuff.

The thing is, I don't think this will solve the mess either. Imagine upgrading the version of Hatari you want to use. There might be a case where a new version has a bug with a game that an older version doesn't, so you want to keep both on your system. So you copy the PND of the new version of Hatari into where the old one is, and have both on your system, both using the same config file. As I mentioned with the UAE4ALL example, this isn't ideal as there might be legitimate reasons why you would want to have different configs for different versions of an app.

To me the issue is not whether you need multiple configs or not, but rather how those multiple configs are handled, and I think splitting out appdata by version number is the most sensible way to do that.

That is NOT something the system has to worry about; developers can take care of their own apps

ie: If version 1,2,3,4,5 of an app work with the same state data, and then v6 breaks it.. their runscript can fix the statedate or move it aside as needed. ie: A developer is the only one who knows enough about his apps to do things sensibly; the OS does not babysit the apps

jeff

I don't see this as a 'mess' at all; we're used to having directories full of stuff in the year 2010 - windows folks are used to /Program Files having 40 applications in it; Your PSP will show 30 apps in a long list; an iPod shows all 200 artists and 1000 albums in a nice long list. So if you have 50 apps on your pandora, and 50 appdata directories in one nicely organized place.. is it so bad? And if it is bad, you're taking issues with every other device out there.. which is fine

 

[mindlord]

@Zeno Arrow - Sounds great, lemme know when you finish writing it.

edit: added target

 

[Zeno Arrow]

Yes, and it's important that you should be able to do this, but how do you handle creating this new appdata folder and creating the config files within?

Of course you could do it all by hand (i.e. make new folder, point app at new appdata folder, run app to create default config for app, tweak app settings to have them virtually the same as another version), but following what I suggested would make this so much easier, it would just be a case of running an app and choosing from a yes/no dialog box, and changing the one or two settings you wished to tweak for that version. Structure of appdata folders would be automatically laid out cleanly too.

When a PND is run it does a sanity check for it's appdata folder. If you've overridden the default appdata folder in the pxml.xml file it doesn't exist, yet. The PND would generate it's folders and configs just like you've run it for the first time. I think you're over thinking this.

You've missed the point. If you change the default appdata folder in the pxml.xml file you are only getting the option of a default config file. If you do it in the way I've laid out you have the option of importing settings from older versions, which means less work to get a new version running how you'd like it to.

 

[WizardStan]

The problem with using one "settings.xml" file as a backup when "settngs_vXYZ.xml" isn't found is that it's not going to let you transfer your custom settings between emulator versions, it's just going to go back to the app defaults every time you upgrade.

The point of my example was that it was a simple example of how it could be handled by the application if such a thing became necessary. It doesn't necessarily have to be handled that way, just that where one example exists there are others, and with brainstorming one of those will become the right way to handle it for the given application. And that's how I think it should be handled: on a per application basis.
It still feels like a bad idea to me, what you're proposing. It's adding extra work (no matter how minor you may think it is) to everyone to account for the very small subset of applications that would actually need the functionality.

 

[Zeno Arrow]

That is NOT something the system has to worry about; developers can take care of their own apps

ie: If version 1,2,3,4,5 of an app work with the same state data, and then v6 breaks it.. their runscript can fix the statedate or move it aside as needed. ie: A developer is the only one who knows enough about his apps to do things sensibly; the OS does not babysit the apps

jeff

I don't see this as a 'mess' at all; we're used to having directories full of stuff in the year 2010 - windows folks are used to /Program Files having 40 applications in it; Your PSP will show 30 apps in a long list; an iPod shows all 200 artists and 1000 albums in a nice long list. So if you have 50 apps on your pandora, and 50 appdata directories in one nicely organized place.. is it so bad? And if it is bad, you're taking issues with every other device out there.. which is fine

If the OS doesn't need to babysit the appdata folders then why was this topic regarding confusing config structure brought up? Just to say, I don't really have a problem with it, I'm just thinking out loud for those that do.

@Zeno Arrow - Sounds great, lemme know when you finish writing it.

edit: added target

Don't have a Pandora to test on. Would you send me a Pandora to develop on if I said I would?

 

[Zeno Arrow]

The problem with using one "settings.xml" file as a backup when "settngs_vXYZ.xml" isn't found is that it's not going to let you transfer your custom settings between emulator versions, it's just going to go back to the app defaults every time you upgrade.

The point of my example was that it was a simple example of how it could be handled by the application if such a thing became necessary. It doesn't necessarily have to be handled that way, just that where one example exists there are others, and with brainstorming one of those will become the right way to handle it for the given application. And that's how I think it should be handled: on a per application basis.
It still feels like a bad idea to me, what you're proposing. It's adding extra work (no matter how minor you may think it is) to everyone to account for the very small subset of applications that would actually need the functionality.

I agree, it should be handled by a per application basis, it's just I'm saying versions of apps differ between each other too.

Adding extra work? Not that much really, especially not for app devs, and the OS stuff only has to be sorted once. What work do you think it'll entail for those involved: OS devs, app devs, users?

 

[WizardStan]

Adding extra work? Not that much really

Any extra work is too much work. If I'm cross compiling something designed to "just work", I don't want to have to add any sort of exceptions for Pandora. I should just compile, wrap it into a PND, and expect that the same data files used for it can work on the same source I've compiled for x86.

 

[skeezix]

That is NOT something the system has to worry about; developers can take care of their own apps

ie: If version 1,2,3,4,5 of an app work with the same state data, and then v6 breaks it.. their runscript can fix the statedate or move it aside as needed. ie: A developer is the only one who knows enough about his apps to do things sensibly; the OS does not babysit the apps

jeff

I don't see this as a 'mess' at all; we're used to having directories full of stuff in the year 2010 - windows folks are used to /Program Files having 40 applications in it; Your PSP will show 30 apps in a long list; an iPod shows all 200 artists and 1000 albums in a nice long list. So if you have 50 apps on your pandora, and 50 appdata directories in one nicely organized place.. is it so bad? And if it is bad, you're taking issues with every other device out there.. which is fine

If the OS doesn't need to babysit the appdata folders then why was this topic regarding confusing config structure brought up? Just to say, I don't really have a problem with it, I'm just thinking out loud for those that do.

@Zeno Arrow - Sounds great, lemme know when you finish writing it.

edit: added target

Don't have a Pandora to test on. Would you send me a Pandora to develop on if I said I would?

It is _not_ confusing, never has been; quite the opposite -- it is very simple and very well defined, and very much like every other system on the planet.

What we are discussing is that DaveC and a few others want the option to move appdata around relative to the app (which is more confusing, but for those people who want it that way, more desirable.)

BTW, for multiple versions -- if the developer or the user want to have multiple versions with their own appdata, they can do that, already, as is But its up to the developer or the user to decide they wish to do it. In general, most apps can use the same state data across versions, and if you want 10 versions of quake, you can.. let them use the same appdata, or developer or user can tell them to use alternate appdata.

jeff