Ok I Tried The Whole Separate Appdata Dir Thing

[DaveC]

Ok so we know that for almost every app a separate directory is made in a directory in a separate spot called "appdata".

We got all kinds of explanations why it has to be this way like making it easer to delete PNDs and leave configs, and because "everything else does it like that" etc. I an not buying those explanations as being so great. It is already a headache.

With hardly any apps released yet I went into this appdata directory as I am deleting updating things. It is a fucking mess! I have things like prboom, prboom.pickle, prboom-1, prboom2wad.pickle, Quake2, ioquake2, ioquake2.pickle, nesemu, nesemu.pickle etc. Now someone else comes out with a Nesemu there will be ANOTHER nesemu-1 or something.

Now if I want to remove or update an app I have no idea what goes with what. If I want to do something with prboom which dir do I use to update things? Which one do the WAD files go in? Where do I put the quake2 data files? Do they go in Quake 2? ioQuake2 or maybe ioquake2.pickle? Which one? how do I know? just keep trying things until it works? Why are there two nesemu directories? What is all of this crap? How confusing!

If there was a way to do what I suggested, but no one would hear of it, and allow this appdata dir to be within the same subdir of the app then this would be much easier to know what is what. If I had a dir called Quake2 with my Quake2.pnd, quake2.ovl, and appdata in that same Quake2 sub dir I would know right away what goes with what. No guessing or trying things until something works. If someone else ported a Quake 2 with a different feature I could have a subdir called something (made up of course) Quake2DX. And in there would be the pnd for that as well as the appdata for that. Now if I wanted to delete or update that I would know exactly which data dir to change. As it is now I would go into the appdata dir and try to sort through a huge pile of hundreds of directories and try to guess what goes with what.

We need to at least make an option to at least have that appdata dir go in the same dir as the app. It would make things so much easier to figure out.

dir Quake2 contains:
Quake2.pnd - executable
quake2.ovl - override for minimenu (optional)
quake2.png - override icon (optional)
Dir: Quake2 - this contains the data (configs, game data, etc) that would hve gone in that big appdata directory.

 

[fearofshorts]

Dude. It's a personal preference thing. You don't like it, I'm sure that somebody will come up with a way to change it to your way.
I, and a lot of other people, love it.

 

[sinoth]

What is all of this crap? How confusing!

You just described the current state of the software on the Pandora

This is something that will get better over time, I think. Once the store matures and people package PNDs correctly your appdata won't be in such disarray.

Still, if you downloaded and installed 3 different Quakes, why complain about there being 3 different directories? Sounds like it is working as expected.

 

[SomeGuy99]

The problem is that you define the appdata dir in the PXML file, and you can set it to anything you want. Really, it should be the same as the name of the PND (and as such the PND name should be unique, including version number etc).

 

[torpor]

I don't like it either, and I'm with DaveC - this is just a mess. If it were at least a bit more self-documenting/sensible it would be tolerable, but "what the hell are all these folders and why do I need them?" is a question I can see a lot of people asking themselves ..

 

[Aninhumer]

The problem is, at the moment people are just rushing to get stuff out there, with no consideration for appdata consistency.
This is not an inherent problem with the PND system, but merely how people are using it.
As soon as things start to settle down, these appdata names can be unified and there won't be a problem anymore.

Furthermore, once these apps start to include setup scripts to find necessary data files you won't even need to go into the appdata directory under normal use.

EDIT: Basically this is like saying Installshield "needs to die" because some companies insist on making the install location "Company Name/Application Name/Version".

 

[RobertJ]

I think it's important to keep application data and configs separate, for a number of reasons.

Firstly it means you can back up all your data without having to backup the usually much larger programs themselves. Secondly, if you need to upgrade or downgrade a program, it can be done easily by nuking the program directory and installing the different version, without losing the data for it. Thirdly it allows you to have multiple versions of the same program, sharing the same configuration settings. Fourthly, it enables a different set of data per user.

Add to that, I doubt anybody has never experienced the awful realisation of losing a valuable document, saved game, or whatever, after uninstalling and reinstalling their software, because it turned out that it was all stored in the archaic system of chucking everything in the same dir as the application itself.

Sounds to me your main problem is with the way people are naming their appdata dirs, and not the concept itself. In which case you should be moaning at the authors for their naming conventions.

Now if you'll excuse me, I'm going back to sleep until my Pandora arrives. Still, nice to have a topic pop up I felt the need to comment on, rather than all the stupid ones posted by what I suspect are 13 year olds wondering whether some Windows game, Windows itself, a peripheral such as a game pad that turns a handheld device into a non-handheld device can be used with the Pandora...

 

[laurencevde]

What you really want is being able to use some variables, such as the pnd's filename, its internal name, the pnd/appdata-directory etc. in libpnd's configuration for an app's appdata-dir. That will allow you to satisfy the way you think...

But there's a very simple performance-reason for not putting all of the app's data in the same directories as the PNDs:
AFAIK, Libpnd currently traverses ALL subdirectories below the configured locations in order to find .PNDs . If you put configuration-directories in there, you'll get a significant amount of additional dirs that need to be traversed. Doing so is slow, especially on FAT...

There are, of-course, ways to "solve" that: you could tell libpnd to not look deeper than a few dirs, use a FS that can be traversed reasonably fast(f.ex: reiserfs) or use symlinks to get your wishes (f.ex: move the .pnd-s to the appdata-dir it created, and put a symlink to it in the pnd-folder, requires a symlink-supporting FS though).

 

[bce23w]

The problem is that you define the appdata dir in the PXML file, and you can set it to anything you want. Really, it should be the same as the name of the PND (and as such the PND name should be unique, including version number etc).

Can't really enforce that without doing an Apple.

 

[fearofshorts]

I think the best thing to do right now is release a REALLY easy to use GUI which automatically sets up the PXML with all of the correct standards. I like to think of this as an electric matter: the devs will just take the path of least resistance.

 

[Aninhumer]

I think the best thing to do right now is release a REALLY easy to use GUI which automatically sets up the PXML with all of the correct standards. I like to think of this as an electric matter: the devs will just take the path of least resistance.

I don't think any dev needs a GUI to edit an XML file, all we need is a well annotated default file that people can read and edit for their purposes.

The important thing is to decide on a standard, and tell people to stick to it.
It's a minimal effort for a dev to change the value in the PXML, all we need to do is make sure they know what it should be.

 

[torpor]

The important thing is to decide on a standard, and tell people to stick to it.

Of all the released apps, which one is the most standard so far? We can just copy that.

 

[Kramy]

EDIT: Basically this is like saying Installshield "needs to die" because some companies insist on making the install location "Company Name/Application Name/Version".

Installshield is really bad, though... no installer at all is superior.

Add to that, I doubt anybody has never experienced the awful realisation of losing a valuable document, saved game, or whatever, after uninstalling and reinstalling their software, because it turned out that it was all stored in the archaic system of chucking everything in the same dir as the application itself.

Other way around. I've got perhaps... 300 games, and only one or two have ever done that. The vast majority leave the folder and saved games untouched.

However, a large number of them that save to My Documents will delete settings and saves without asking, when you uninstall. :huh: That's not an issue here... but it does explain me COMPLETELY agreeing with DaveC in thinking this is stupid. Not only does it make the config files more difficult to find - it also makes it harder to clean up your SD card, and keep important settings when migrating versions. (as opposed to just using whatever is in the same folder as the PND)

I dump games in subfolders, and when I want to remove them I delete them. Now I have to hunt around for some crappy hidden files to keep my SD clean - or just periodically delete the whole thing.

Meh.

 

[juniorm33]

Although nothing wrong with having a tool GUI or otherwise.
One that validates the PXML to the standards laid out which isn't currently the case.
It could then create the PMD also.

I'm aware that some PXML's are incorrect because of early days, rush to get the apps out etc.
But there's nothing wrong with a tool/app/script/gui to validate/help.

 

[BaDToaD]

As things are a bit rough around the edges at the moment. I intend to have a dump SD card that I just throw pnds at to test out and use my other SD cards for the ones I want to keep.

to be fair to the devs they have always stressed the location can be changed if you wish.

 

[juniorm33]

As things are a bit rough around the edges at the moment. I intend to have a dump SD card that I just throw pnds at to test out and use my other SD cards for the ones I want to keep.

to be fair to the devs they have always stressed the location can be changed if you wish.

Sure everything is rough (and to be expected) but something to at least validate the PXML would be a very useful thing very early on to have.

 

[Aninhumer]

However, a large number of them that save to My Documents will delete settings and saves without asking, when you uninstall. :huh: That's not an issue here... but it does explain me COMPLETELY agreeing with DaveC in thinking this is stupid. Not only does it make the config files more difficult to find - it also makes it harder to clean up your SD card, and keep important settings when migrating versions. (as opposed to just using whatever is in the same folder as the PND)

I dump games in subfolders, and when I want to remove them I delete them. Now I have to hunt around for some crappy hidden files to keep my SD clean - or just periodically delete the whole thing.

You could just not care about a few KB of extra storage. But yeah I'm a filesystem clean freak too...

Personally I don't consider it significant extra effort to delete two things instead of one, on the few occasions when I don't think I'll ever use something again.
If you're really that bothered, it would be simple enough to make XFCE custom actions for "Open data directory" and "Delete local files".
Alternatively, if you insist on having everything in the same directory, you can just extract your PNDs and use them as good-old-fashioned game dirs.

 

[dflemstr]

OK, guys, listen up!

I'm going to create a canonical PXML.xml file with sane defaults filled in, and with comments that say exactly where everything belongs etc. In return, I would like this file to be used *everywhere* as much as possible, including already uploaded PND files (Replace the PXML, please!), and that people don't try to "push the limits of the standard" too much after that.

Deal?

 

[BaDToaD]

OK, guys, listen up!

I'm going to create a canonical PXML.xml file with sane defaults filled in, and with comments that say exactly where everything belongs etc. In return, I would like this file to be used *everywhere* as much as possible, including already uploaded PND files (Replace the PXML, please!), and that people don't try to "push the limits of the standard" too much after that.

Deal?

Sounds good but this warrants it's own topic to insure everyone reads it.

 

[dflemstr]

OK, guys, listen up!

I'm going to create a canonical PXML.xml file with sane defaults filled in, and with comments that say exactly where everything belongs etc. In return, I would like this file to be used *everywhere* as much as possible, including already uploaded PND files (Replace the PXML, please!), and that people don't try to "push the limits of the standard" too much after that.

Deal?

Sounds good but this warrants it's own topic to insure everyone reads it.

I'll create one this evening when I'm done with writing the file (it's gotta be done properly).