Ok I Tried The Whole Separate Appdata Dir Thing

[Zeno Arrow]

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.

The only extra work I'm proposing for the app dev is to add a couple of extra lines (for default settings) into the PXML file. Hardly a huge issue is it.

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

Perhaps confusing was the wrong word, sorry.

I agree with what you said before about appdata moved around with the app being a personal preference thing, but to me the issue is not where the appdata is stored but how it is organised. Some think moving appdata around with the app will make it more clearly organised, I disagree, but I've explained why that is already so I'll let y'all carry on the bikeshedding in peace.

P.S. Thank you for your Pandora work skeezix, I do appreciate it.

 

[skeezix]

you're right, this is definately bikeshedding to some extent; or 'lots of recipe writers in the kitchen'

In the end, I fully expect folks to write 5 different package managers to do random things like 'uninstall' (delete appdata + pnd file), or other 'organizers', along with pnd-repository-updaters and such. But I figure evolution can take that on .. people will write what they need, and we'll see what sticks

jeff

 

[Exophase]

skeezix & dflemstr, thanks for the clarification. So yeah, no problem with the system then. Just one question: if the user already makes the PND's appdata directory in advance what happens? I ask because for some users I think it'll be more straightforward to dump the syscards in the syscard directory rather than having to run the emulator first for that directory to be created, then exiting the emulator and throwing the syscards there.

 

[gibberish]

i've created the appdata dir first for both quakes and for race and it's worked out ok.

 

[Exophase]

i've created the appdata dir first for both quakes and for race and it's worked out ok.

Did you have things in there too? Were they preserved?

 

[DaveC]

ie: This particular one basicly pushes more organization requirement and discipline onto the user, but has some long term payoffs; its certainly not good for a lot (most?) people, imho -- forcing them into a discipline day zero.

ie:

Consider -- if they just throw all their pnd files in one place, they end up with essentially what hey already have,m but a bit more messy.

This change only benefits those who go so far as to put each pnd file in its own directory, or in logical clumps, which I can't see average joe shmoe off the street doing _day zero_.

ie: I'm fairly sure the default behaviour is right, in that its the same more or less as every major OS in the last decade, and two.. its very easy to use, with no set up. Thats 'right'.
But as in all things, options are good, and as everyone knows, I do love me having a million options.

Its simply configuration choice; some people like it one way or another, but the average joe day zero has to be factored in

It is not good for most that don't have photographic memories like me.

You seem to think one just places a pnd on the card, run it and is then fat dumb and happy. That might be true for a few things BUT. Many things require users to place things in a spot after they put the pnd file on their card anyway. You know BIOS files for emus, data files for Quake, WADS for doom, data files for all DOS games that can't be included etc. The user is now forced to set things up anyway. Now imagine this user is greeted with a wall of directories all thrown in one huge pile in appdata. Many times with multiple directories per app. I have seen this already. I ran quake 2 and found directories Quake2, ioQuake2, Quake2.pickle in appdata. a few of those may be from older versions that I deleted but forgot to remove the appdata part. So where the hell do the PAK files go? I sat there for a half hour trying things one by one until afer awhile it worked.

Imagine when we get hundreds of apps that we are constantly testing and upgrading. This pile of appdata dirs is going to get unwieldy. Unneeded junk will start to clutter up the directory as users forget to delete old ones. It is not intuitive because in a different spot it is not obvious.


You also can't catagorize your directories the way it is. Since everything MUST be in one massive pile mixed together in the directory, games, emus, utilities, etc you can't pare down this mess into logical clusters. You can't have all emu appdata dirs in the emu dir in the particular emu's folder, all game appdata in the games particular dir etc. To me everything mixed together is much more messy than things clustered in logical directories that make some sense.

I keep hearing the argument that because other OSs do it that means it is good. No that just means other OSs do it. That doesn't mean it is good or desirable. How many out there rave about how great Windows is because it sprays things all over and balloons the registry with all kinds of crap?

 

[gibberish]

i've created the appdata dir first for both quakes and for race and it's worked out ok.

Did you have things in there too? Were they preserved?

yup i dumped the pak files for both quakes and some roms for race in the manually created appdata dirs before running the pnds and everything was preserved afterward.

 

[Exophase]

Like others have said, it won't be hard to have a program which cleans up the appdata directories based on whether or not any searched for PNDs are tied to it. Maybe a hidden file can be maintained in the directory which says which PND created it and which most recently accessed it. That way the browser can report this stuff, if they weren't nicely named and organized by the PND.

yup i dumped the pak files for both quakes and some roms for race in the manually created appdata dirs before running the pnds and everything was preserved afterward.

Thanks, sounds good then.

 

[EvilDragon]

i've created the appdata dir first for both quakes and for race and it's worked out ok.

Did you have things in there too? Were they preserved?

They are. If the same files exist, they have higher priority.
i.e. if you are a developer and are working on a new version, you can keep your old PND file on the card and copy the new executable into the appdata directory - if you run the PND, the new executable will be used.
This is pretty useful if you're game uses datafiles, e.g.

On the other way round, people could put new Levels for SuperTux or similar games into the appdata dir and the game will use them.
If they delete them again, the game is back to its original state.

You seem to think one just places a pnd on the card, run it and is then fat dumb and happy. That might be true for a few things BUT. Many things require users to place things in a spot after they put the pnd file on their card anyway. You know BIOS files for emus, data files for Quake, WADS for doom, data files for all DOS games that can't be included etc. The user is now forced to set things up anyway.

While that's true for the beginning, as most users want ports of Emulators and popular games, there will be the time when there will be A LOT more original games for the Pandora as Emulators or any interpreters.
I can't think of many more than about 40, but I know more than 40 Linux games that could be ported to the Pandora - nothing more to be done.

Also, it's up to the dev: Each PND can help you setup your files. It could ask you to show where you have the datafiles and move or copy them over to the proper directory.

Also, the appdata directory is not the one that should be used for datafiles - AFAIK we already have support for data folders within PXMLs, it's just not used.

Additionally, each game can be setup to ask the user where those files are and use that data directory.
The games don't do that yet - but that's no fault of the PND system but of the coder.

If the emulators on the gp2x wouldn't support setting the paths for the roms, you would have to place all the roms in the emulator directory.
That's a thing the dev has to do - NOT the PND system.

 

[cosurgi]

Of course it has to die. I had exactly the same experience with Rox Desktop Appdirs. I was flamed to death about that on rox mailing list. Appdir is a hell on steroids.

we need dpkg -like package management. It's very well tested. And everyone who tried it - loves it.

The simplest way to achieve this: use debian instead of angstrom You only need to make a debian package with pandora's linux-image. All other packages that pandora is flashed with are already present in debian, you just download them.

Then - when releasing a game or other software, just use the debian's build system to create .deb files. This was tested for more than 10 years. It has to work better than this whole "reinvent the wheel" PND stuff.

 

[DaveC]

Like others have said, it won't be hard to have a program which cleans up the appdata directories based on whether or not any searched for PNDs are tied to it. Maybe a hidden file can be maintained in the directory which says which PND created it and which most recently accessed it. That way the browser can report this stuff, if they weren't nicely named and organized by the PND.

yup i dumped the pak files for both quakes and some roms for race in the manually created appdata dirs before running the pnds and everything was preserved afterward.

Thanks, sounds good then.

Ugh, this reminds me of all of those windows programs needed to clean up after the messiness of the os.

I think it would just be better to make it more logical in the beginning, then we wouldn't need all of that.

If the apps data dir was in the same dir as tha app we wouldn't need this kind of thing. It would make sense. If you want to delete the app just nuke its subdir.

 

[cosurgi]

Ugh, this reminds me of all of those windows programs needed to clean up after the messiness of the os.

I think it would just be better to make it more logical in the beginning, then we wouldn't need all of that.

this sounds like reinventing the /var/cache/apt/pkgcache.bin file from debian ;p

 

[DaveC]

Couldn't this be as simple as having one override file In a designated spot on the SD that would tell pnds to do it as I said with putting the data dir in the same folder as the app? The pnd would look for this file on startup. If the override is not there it just does it as it does now.

This way everyone is happy.

 

[EvilDragon]

We've got OPKG on Angström, which even uses Debian packages... so that's basically the same.

Let me know Cosurgi: How do you plan to install apps using APT-GET on your SD-Card without having any database problems or missing dependencies for some games in case your SD Card is lost?
And please let me know how to manually install apps in Debian onto an SD Card in case you don't have a WiFi connection at the moment and want to try out a new app on your Pandora?

 

[Asiyura]

A PND repository and his manager would be great and it has been said that it's totally doable (end maybe even planned, can't remember).
PND system is a pretty good system for a handheld console where softwares are on removable media.

They didn't reinvent the wheel, they made a system that allow to manage the apps on the pandora's SD card on a desktop computer, whatever the desktop's OS.
I know many of the pre-orderers consider the Pandora as a full-fledged computer and are going to do everything on the Pandora.
But for the average gamer, the pandora is a handheld console; they're going to download games on their faster than wifi desktop, drop those PND in the SD, put the SD in their pandora, flip the pandora on and start to play.

 

[cosurgi]

Let me know Cosurgi: How do you plan to install apps using APT-GET on your SD-Card without having any database problems or missing dependencies for some games in case your SD Card is lost?
And please let me know how to manually install apps in Debian onto an SD Card in case you don't have a WiFi connection at the moment and want to try out a new app on your Pandora?

thanks for reminding me about the use case, that I forgot about h34r:

In debian you can rebuild pkgcache from "nothing" - just by scanning /usr and /share dirs. So the problem of losing SD card is solved, although that rebuild is time consuming.

Installing apps offline worked for years by using debian CDROMs. Here we would need whole pandora repository downloaded onto some medium, like usb stick.

If you don't like this, you could use apt-get to spit out a list of packages that it wants to download. A short script would convert that into an executable (.bat for windows, .sh for linuxes), which you would execute on another computer to download all those required files, then go back to pandora and install all downloaded files.

complicated though.

And above all, this would require all games to be .deb packages. Which many people won't like. It's much easier to whip out a .zip file. I know.

I am sure that once I get my pandora I'll be fiddling with debian until it will be running in a comfortable manner. I hope to get help from other debian maniacs in this aspect. I am sure that in a year or two we will have a nice debian based repo for pandora. And I will be just a tiny part of that effort.

 

[Olexxy]

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

jeff

Actually why isn't it the case (/home/username without the initial /pandora) ? Don't have my pandora yet so can't comment much, but I thought you would just use standard linux tree system with clever merging with user info on nand and/or sd ?

 

[dflemstr]

We've got OPKG on Angström, which even uses Debian packages... so that's basically the same.

Let me know Cosurgi: How do you plan to install apps using APT-GET on your SD-Card without having any database problems or missing dependencies for some games in case your SD Card is lost?
And please let me know how to manually install apps in Debian onto an SD Card in case you don't have a WiFi connection at the moment and want to try out a new app on your Pandora?

EvilDragon, please see this post: http://www.gp32x.de/board/index.php?/topic/54064-advanced-filesystem-hackery/page__view__findpost__p__870331

opkg *does* have functionality built-in for externally installed applications. The technology has always been there.

I've always had the impression that OP wanted to go a different route "just to be different", e.g. to offer an unique software product. There is not really a rational *reason*, however; opkg could as easily have been used as a starting point as PXML could have.

 

[EvilDragon]

We've got OPKG on Angström, which even uses Debian packages... so that's basically the same.

Let me know Cosurgi: How do you plan to install apps using APT-GET on your SD-Card without having any database problems or missing dependencies for some games in case your SD Card is lost?
And please let me know how to manually install apps in Debian onto an SD Card in case you don't have a WiFi connection at the moment and want to try out a new app on your Pandora?

EvilDragon, please see this post: http://www.gp32x.de/board/index.php?/topic/54064-advanced-filesystem-hackery/page__view__findpost__p__870331

opkg *does* have functionality built-in for externally installed applications. The technology has always been there.

I've always had the impression that OP wanted to go a different route "just to be different", e.g. to offer an unique software product. There is not really a rational *reason*, however; opkg could as easily have been used as a starting point as PXML could have.

Well, I know that, but you still need to INSTALL those packages.
There's no real easy way to manage everything by simply copying the file onto the SD Card, run it and delete it if you don't need it anymore.

You still need an SD Card where you install the apps, another place to install the IPKs from, etc.
Without WiFi, manually downloading means you also need to check out what dependencies are needed and therefore need to download more and more and more packages.

 

[JDGBOLT]

Okay, this is just an idea that I had, feel free to bash it or whatever. I haven't got my pandora yet, so I can't say for sure that I've used the pnd system in it's current configuration. But I figured I would put it out there, and if it has been suggested already in the thread, well, I guess I missed it in reading through the thread. Anyway, I would think a median solution to all this could be having the default appdata directory being the name of the pnd file, but if there were potentially conflicts, due to say different versions or whatever, it could fallback to using the name configured within the pxml file. And of course adding the option for an override within the appdata directory to make it possible for multiple apps to say use the same appdata. Now, potentially it could be using the name of the app that is configured in the pxml file. Though I think just having it named after the pnd file would minimize the risks for overlap, as the filesystem wouldn't exactly like multiple pnd files named the same thing. I think it would be least confusing. But I may be wrong on this. Anyway, feel free to flame away.