Improvements To The Pnd System

[Aninhumer]

I used save states as an example, but the same is true for configuration files or other data read or written by an app. I guess we'll have every app open a file picker when it starts so you can specify where your configuration file is? Or maybe the user could specify paths in some kind of file under appdata - oh, wait...

The user shouldn't need to access config files, because the app should have an options menu.

By making this directory harder to get to, devs remember they shouldn't be putting saves in it.

Why on earth not? This is data pertaining to the application == application data == appdata.

For the same reason you shouldn't put roms in there, you might want to access them from more than one emulator.
I know there tend to be incompatible savestate formats, but at least SRAM saves are pretty standard.
You could equally well say documents are "data pertaining to Abiword", but no one would suggest you store them all in appdata.

EDIT: As you say, the discussion of whether pandora/ is hidden or not is irrelevant.
But the discussion about what should and should not go in appdata is important.
Basically I want to avoid, for example, as happened in the past, users having to copy bios files into exactly the right place before something will work.
This creates dozens of confused users, and the zenity frontend to avoid that is a few lines of script.

 

[dgame]

I would like to be able to stop some icons from showing up on the desktop. Can this be done manually?

Yes, put the PND in the menu directory.

As for the multiple apps in one PND debate then I'm with DaveC on that one, it is not something I like. With the prices of 8GB cards being not much more than £10 then losing a few hundred MB of space to duplicated libraries / files is a price worth paying for the User being able to install the apps they want.

It's a multiple apps in one PND and I only want one of the apps to show on the desktop.

 

[WizardStan]

It's a multiple apps in one PND and I only want one of the apps to show on the desktop.

Create an OVR file which only contains the apps you're interested in.
*IDEA* A tool that opens PND files, displays all the apps that the PXML exposes, and allows you to check/uncheck them, then spits out an OVR file. Possibly allows additional customization.

 

[Tom`]

It's a multiple apps in one PND and I only want one of the apps to show on the desktop.

Create an OVR file which only contains the apps you're interested in.
*IDEA* A tool that opens PND files, displays all the apps that the PXML exposes, and allows you to check/uncheck them, then spits out an OVR file. Possibly allows additional customization.

I already had that idea earlier in the thread.

I expect when someone writes a tool to work with PND files, it'll be easy to get rid of stuff you don't want, though.

 

[WizardStan]

I already had that idea earlier in the thread.

Sorry Tom. I kinda skimmed the thread and missed that line.
It just goes to show what a great idea it is, though! If two people thought it up, how could it possibly be wrong?

 

[cosam]

The user shouldn't need to access config files, because the app should have an options menu.

Yes, most apps should have a menu but a lot of them don't and some never will. There are also apps (e.g. daemons and such) which can only be configured using text files and these should be easily accessible. That a user shouldn't usually need to access something doesn't imply that it has to be made invisible to them.

By making this directory harder to get to, devs remember they shouldn't be putting saves in it.

Why on earth not? This is data pertaining to the application == application data == appdata.

For the same reason you shouldn't put roms in there, you might want to access them from more than one emulator.
I know there tend to be incompatible savestate formats, but at least SRAM saves are pretty standard.
You could equally well say documents are "data pertaining to Abiword", but no one would suggest you store them all in appdata.

I would agree that it should be possible to store data useful to more than one app outside of appdata. I would however argue that appdata is a reasonable default location for this kind of stuff. The user should not have to create directories (or have random directories created for them) in order to be able to save data. The option to specify a location would of coruse be good, but it's unrealistic to expect that from every app.

EDIT: As you say, the discussion of whether pandora/ is hidden or not is irrelevant.

I don't think I said that; I believe it is relevant. Hiding pandora and/or appdata is proposed as an improvement to the existing system and I don't think it is one. I don't see any real advantage in hiding it, but there are several good reasons not to.

But the discussion about what should and should not go in appdata is important.
Basically I want to avoid, for example, as happened in the past, users having to copy bios files into exactly the right place before something will work.
This creates dozens of confused users, and the zenity frontend to avoid that is a few lines of script.

Agreed. My point is that hiding appdata isn't going to make any difference at all in this regard. Developers will make things easy to use if they want to; if they don't, they won't. There's however nothing stopping anyone with the appropriate skills from packaging another developer's work, or providing scripts or patches to make packages more user friendly.

 

[Aninhumer]

Create an OVR file which only contains the apps you're interested in.
*IDEA* A tool that opens PND files, displays all the apps that the PXML exposes, and allows you to check/uncheck them, then spits out an OVR file. Possibly allows additional customization.

I think replacing the file based menu/desktop options with some kind of proper tool would solve the problem.
Not that there aren't other uses for such a tool, but in this case you're talking about using it as a workaround to a bigger problem.

@SteveM
Thank you for raising so many issues.
The goal is ease of use, and you're probably right that hiding the directory won't solve the problems.
We should aim to solve the problems directly, and we have a lot more opportunity to do so on the Pandora.
I'm forgetting that we didn't have things like Zenity on the GP2X, and it should make quick interface creation a lot easier.

 

[mali]

Split last few posts as per request to new topic: http://www.gp32x.de/board/index.php?/topic/55631-theming-zenity-using-gtkrc/

 

[Tobriand]

One thought: Even on a Mac, appdata, configuration files, and the like are visible to the user. Macs are supposed to be the single most user friendly systems available on the planet, currently, at least if you listen to Apple fans. If they get away with leaving obscure stuff visible (just in a place most people won't need to access it), then there's no reason we shouldn't.

However, I must admit I would prefer it if the second part of that statement were true: ideally, we really shouldn't need to access appdata. Certainly not to create empty directories or move data there, in any event.

Hmm... a thought crosses my mind. Does the .PND specification allow for a shell script called install.sh to be run if an appdata directory is not detected? Thus, on running the app for the first time:
- Appdata is created
- Any directories that are needed are created, including empty but required files (Ur-Quan Masters, I'm looking at you)
- The user is prompted to choose a location for their data files, probably much the same way that ScummVM does it - i.e. choose a directory, and the programme works out where everything is
- The install script works out where everything should be, and either reconfigures the paths internally, or asks the user permission to shuffle the files to where they need to be. Ideally, the script should be capable of parsing popular compressed formats to identify where the relevant files are and yank them out.
- The application finishes installing, and just works from then on

It would make things from a user's point of view a LOT easier...

 

[Aninhumer]

Hmm... a thought crosses my mind. Does the .PND specification allow for a shell script called install.sh to be run if an appdata directory is not detected?

There are other ways to detect a first run.
For example you could just have the script touch a "setup-completed" file, and only run if it isn't there.
But yes all of those things can be done, I'm hoping to work on zenity scripts like that once I get my Pandora.

 

[DaveC]

One thought: Even on a Mac, appdata, configuration files, and the like are visible to the user. Macs are supposed to be the single most user friendly systems available on the planet, currently, at least if you listen to Apple fans. If they get away with leaving obscure stuff visible (just in a place most people won't need to access it), then there's no reason we shouldn't.

Apple is a bad example. They are control freaks and don't want pesky lowly users poking in their "art" OSes.

Pandora is different it is meant to be hacked around with. Solution is simple, don't want to mess with directories then don't! Hiding them just makes it a pain for those of us who want to see them.

 

[Prometheus]

That's actually an excellent example. The way it is on the Pandora right now is quite similar to the stock behaviour on Mac OS X.

To clarify: Mac OS X has the directory "Library" (well, actually there's a system-wide one, and one for each user), which is pretty much directly equivalent to the current /pandora/appdata setup. Sometimes, users of some applications even have to go in there and place a file or a folder so that their application can work. It's also where frameworks that allow certain stuff to run are meant to be placed - users are completely allowed to go in there and poke around. If you'd like an example, if memory serves, to use Richard Bannister's Emulator Enhancer add-on (available for free trial), you have to drop a folder in your user account's Library.

EDIT: Come to think of it, it even has the uniquely-named directories relating to each app, and it can even cause similar freak-outs if you leave outdated configuration files in them, too. Hell, sometimes you even find confusingly-named app-directories in there, because that's what a developer or company went with, although like the Pandora, for the most part it's very easy to recognise what's what.

 

[Tobriand]

I think the main point I was making is that even Apple, with all their control freakery and consequential reputation for being easy to use have a system that's quite similar on a unix-based platform that almost anyone can become comfortable with in a couple of days.

It's just that, even if once in a while going in there is necessary, most people never have to - and it would be nice if this part was replicated on Pandora eventually...