Improvements To The Pnd System

[Aninhumer]

First of all, I'd point out that like most people here, I don't actually have my Pandora, so my comments are based only on what I've read.
Anyway...

In my opinion, the PND system is an excellent idea, but one which is currently not serving the purpose it was designed for as well as it could.

Requiring users to place PND files in a specific set of directories means the goal of "copy and play" is not being met.
Now I know that doing a full scan of the SD every time it is inserted isn't practical, but I'm not sure why this can't be avoided?
Surely a cache could be kept and only modified files scanned? And while the SD is mounted, new .pnd writes can be monitored by the linux kernel.

This would also mean an alternative would be needed for selecting menu/desktop items, but I never thought that using folders was a sensible idea anyway.
A simple zenity checkbox script would be a perfectly good short term menu/desktop item selector. (and I may yet write one)
It also allows people to select only the apps they want in PNDs with multiple apps.

Both the PND list cache and the menu and desktop lists could just be kept as simple text files in the "pandora/" directory.


Moving on, a slightly more controversial suggestion, and perhaps more long term: Make the remaining "pandora/appdata/" directory at the root of SDs hidden.
I don't believe a normal user should ever need to access this directory. If an application has configuration it should be accessible via menus.
As a temporary solution or for advanced options, a PND could include an "edit config" app which just opens the config in the default text editor.
For Beta apps where data folder access might be needed a lot, devs could just release as a .zip for testing, and package it later.

If I'm honest this is more about hiding clutter for me than being that useful , but it would fit better with the "hidden directories in $HOME" config model that it's based on.

Thoughts? Or indeed further suggestions for improvements or problems people have?

 

[dflemstr]

I +1 this, and also:

1. Make all PNDs show up in the menu by default. If I want a desktop icon, I'll drag-drop it to the desktop. And if I pull out my SD card and still have the shortcut icon on the desktop... so what? First of all, I wouldn't put apps that I tend to not be using on the Desktop, so the apps will stay mounted most of the time anyways. Secondly, you can configure XFCE to hide "broken" symlinks and .desktop files, and if you can't do that in this specific XFCE version, it's easy to patch in.
2. Use the XDG standard for everything. Why does libpnd use its own config files? Everything it needs is available through XDG environment variables, and XDG tools.
3. Use an initial scan and then inotify on the whole SD card to discover PND files. That way, there's no overhead and no need to create a "PND cache" or some such; you let the Linux Kernel discover the PNDs for you.
4. Rename "...sd/pandora" to "...sd/.pandora" so that it's hidden. Make GUIs for "installing" data files for Quake etc.

I'm ready to do this myself, but I can't since I have no way of testing what I'm doing. The PND system is so entangled with the Pandora system that I need a Pandora to do proper changes.

 

[DaveC]

A simple zenity checkbox script would be a perfectly good short term menu/desktop item selector. (and I may yet write one)
It also allows people to select only the apps they want in PNDs with multiple apps.

Moving on, a slightly more controversial suggestion, and perhaps more long term: Make the remaining "pandora/appdata/" directory at the root of SDs hidden.
I don't believe a normal user should ever need to access this directory.

Well I dislike multi-app PNDs to begin with. I think in general it is a bad idea. I mean what is the advantage? Maybe to save a few K for shared data? Not worth it. For example a VICE PND may include emulators for C64, Vic-20, Commodore plus 4, PET models, C128 etc. So now I have a big wad of dead icons with no supporting ROMs cluttering up my minimenu emu page and all I really care about is C64!

Same with Quake, it includes modules and icons for all kinds of paks. I only have one pak so now I have a bunch of icons cluttering my menu and most of them are dead. It sucks. It is a dumb idea and I can only se a couple of cases to use it. I mean if I have all of those modules what is the big deal having separate PNDs? I would then have the same amount of icons. It is dumb.

Hiding the appdata dir is a terrible idea though. What if (and this happens allot) I try an app, don't like it and delete it? I don't want a bunch of orphaned appdata directories full of crap hidden on my card!

 

[Tom`]

Well I dislike multi-app PNDs to begin with. I think in general it is a bad idea. I mean what is the advantage? Maybe to save a few K for shared data? Not worth it. For example a VICE PND may include emulators for C64, Vic-20, Commodore plus 4, PET models, C128 etc. So now I have a big wad of dead icons with no supporting ROMs cluttering up my minimenu emu page and all I really care about is C64!

Same with Quake, it includes modules and icons for all kinds of paks. I only have one pak so now I have a bunch of icons cluttering my menu and most of them are dead. It sucks. It is a dumb idea and I can only se a couple of cases to use it. I mean if I have all of those modules what is the big deal having separate PNDs? I would then have the same amount of icons. It is dumb.

Hiding the appdata dir is a terrible idea though. What if (and this happens allot) I try an app, don't like it and delete it? I don't want a bunch of orphaned appdata directories full of crap hidden on my card!

Then just disable the "hide directories beginning with ." option.

Anyway, I agree that it's probably useless in the majority of circumstances, but it makes sense to have a multiple-app PND in cases where supporting files are large. 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.

 

[wdt]

?Thoughts? Or indeed further suggestions for improvements or problems people have?

Not exactly what you had in mind but...

The daemon should ask OS does this card have a swap partition?
Is it referenced in fstab? ( by label easiest, I have a complicated scheme)
Then assume fstab is correct, swapon -a
But how to do a clever swapoff?

dave

 

[Prometheus]

I'm pretty sure that Aninhumer was talking purely about the PND system, not other things relating to the operating system.

 

[Aninhumer]

Use the XDG standard for everything. Why does libpnd use its own config files? Everything it needs is available through XDG environment variables, and XDG tools.

What would this involve (apart from .desktop files)? I'm not really familiar with the XDG spec beyond .desktop and "xdg-open".

Use an initial scan and then inotify on the whole SD card to discover PND files. That way, there's no overhead and no need to create a "PND cache" or some such; you let the Linux Kernel discover the PNDs for you.

I think what you're describing is basically what I said? I just forgot what inotify was called.
The "cache" is just a list of paths in some form (that could be a bunch of .desktop files I guess, but I think having an easily accessible list would be good too).
Also, you'd still need to scan the SD every insert in case the user has added anything from a PC, unless inotify can scan filesystems for changes on mount?

Rename "...sd/pandora" to "...sd/.pandora" so that it's hidden. Make GUIs for "installing" data files for Quake etc.

That's what I meant.
I also think putting data files in appdata is a bad idea, because while orphaned files aren't really important when they're a few KB, having several MB of data that's difficult to delete could really start to eat into people's space.
I think apps should let the user put it where they like and keep a reference of where it's stored. (I don't think you can symlink on FAT32?)
It would be easy enough to do that with zenity frontends, as long as the app can take a path for its data files.

Well I dislike multi-app PNDs to begin with. I think in general it is a bad idea. I mean what is the advantage? Maybe to save a few K for shared data? Not worth it. For example a VICE PND may include emulators for C64, Vic-20, Commodore plus 4, PET models, C128 etc. So now I have a big wad of dead icons with no supporting ROMs cluttering up my minimenu emu page and all I really care about is C64!

Same with Quake, it includes modules and icons for all kinds of paks. I only have one pak so now I have a bunch of icons cluttering my menu and most of them are dead. It sucks. It is a dumb idea and I can only se a couple of cases to use it. I mean if I have all of those modules what is the big deal having separate PNDs? I would then have the same amount of icons. It is dumb.

I agree that separate PNDs would be better for things that are definitely discrete, and I agree that having multiple "apps" for different launch options is also bad idea, but there are still potential use cases. As long as you can hide them, it isn't much of an issue anyway, perhaps we should have an option for them to be hidden by default. I think we should also probably have something for devs saying "If you're planning on using more than 2 apps in your PND, you're probably not doing it right".

Hiding the appdata dir is a terrible idea though. What if (and this happens allot) I try an app, don't like it and delete it? I don't want a bunch of orphaned appdata directories full of crap hidden on my card!

Then just disable the "hide directories beginning with ." option.

Yeah I'm just talking about defaults for the average user, it should still be easy to change for people that want to.
Reverting to a visible directory would probably be a better idea than not being able to hide things at all.
Although I get the impression DaveC would rather have them all visible so he can complain about them...

 

[grahamr]

remove hierarchy of pnd placement
+1
Ok, this 'removes' the flexibility of choosing how the program appears, but so what? Its not something most normal users want to muck around with. You could have like a system setting 'create desktop icons for programs' and that sort of thing to sort out general preferences for ALL apps, and quirks dealt with in .appdata. but personally I don't want or need this functionality, i just want the program to show up somewhere so i can run it, im not that bothered about where.

make appdata hidden
+1
just put a . in front of it. This is common practice for application data on the desktop, and i think its a good one.. i don't want to see that crap, but I know i can go looking for it if i want to.

Straying just slightly off-topic - Personally my biggest problem with .pnd at the moment though is just there isn't enough of them, and that they arn't all in the repository. I would like to see a lot more "easy" ported stuff (e.g. stuff just pulled out of the Angstrom repository) put into .pnd format. I havn't bothered doing this yet myself, as I imagined they would be 'easy wins' that other people would be picking up (i am spending my pandora-time trying to write a game).
You *can* find pnds for this and that, but they are scattered around the internet instead of in the repository and are often 'beta'.

 

[Bosbeetle]

hmm ive been doing quite a lot in appdata, putting in data files, removing folders is a nice way to 'reset' apps etc etc

Shouldnt be hidden imo

I like the way it is organized now. (could be a bit more uniform but thats up to the devs)

 

[sebt3]

Straying just slightly off-topic - Personally my biggest problem with .pnd at the moment though is just there isn't enough of them, and that they arn't all in the repository. I would like to see a lot more "easy" ported stuff (e.g. stuff just pulled out of the Angstrom repository) put into .pnd format. I havn't bothered doing this yet myself, as I imagined they would be 'easy wins' that other people would be picking up (i am spending my pandora-time trying to write a game).
You *can* find pnds for this and that, but they are scattered around the internet instead of in the repository and are often 'beta'.

huhh ? Not enough of them ? At least a release a day since pandora started shipping, that's not enough ? then join the fun.
I tried to fill all the legitimate needs I found on these board before taking care of what *I* want.
I've been ninja'd on ports more than once.
Jeez, I can't believe that some find this is not enough. Want more ?

Sure most my pnds still requiere love to be good enough. But we are'nt pumping these fast enough anyway

This scene is way more active than the Wii scene. Now compare ownership...

 

[Aninhumer]

Straying just slightly off-topic - Personally my biggest problem with .pnd at the moment though is just there isn't enough of them, and that they arn't all in the repository. I would like to see a lot more "easy" ported stuff (e.g. stuff just pulled out of the Angstrom repository) put into .pnd format. I havn't bothered doing this yet myself, as I imagined they would be 'easy wins' that other people would be picking up (i am spending my pandora-time trying to write a game).
You *can* find pnds for this and that, but they are scattered around the internet instead of in the repository and are often 'beta'.

The main issue is the shortage of people with Pandoras atm...
I think there might be more "easy wins" from compiling from source tarballs than the angstrom repo.
The problem with repo stuff is that it's already rearranged for the unix filesystem layout, so has to be more extensively modified to make a PND. (I could be wrong, haven't tried it myself).

I've seen several people having problems making PNDs, and I'm not certain why (not saying it's their fault).
AFAIK if someone can get something working in a directory all they need to do is make a PXML (easy with dflemstr's annotated one) and mksquashfs it up.
Are there some complications with the system that are making this more difficult?

Perhaps there could be a "Porting Attempts" thread, where people can post output from attempted compiles.
Experienced devs can usually tell straight away what a problem was, and how much effort it would take to fix.
It would also help to avoid duplicated effort.

hmm ive been doing quite a lot in appdata, putting in data files, removing folders is a nice way to 'reset' apps etc etc

Well that's rather my point, none of that should be necessary, and making it hidden would help to remind devs that the shouldn't just rely on the user being able to mess about in there.
The point about being able to reset is something I hadn't thought of though.
I'd say devs should design things so that settings won't break them, but that's not really a solution...

Did anyone get around to making that "delete appdata" XFCE custom action for .pnd files?

 

[cosam]

Hiding appdata wouldn't do anything other than get in the way. It isn't comparable to hiding the subdirectories of $HOME, it's comparable to hiding the whole of $HOME itself. The convention of hidden files in $HOME makes sense as it will usually contain other stuff. Appdata contains no other stuff so if you're in there you want to see it. You might as well make /etc hidden or the whole NAND filesystem as, going these standards, no "normal" users have any business looking there either.

 

[Aninhumer]

Hiding appdata wouldn't do anything other than get in the way. It isn't comparable to hiding the subdirectories of $HOME, it's comparable to hiding the whole of $HOME itself. The convention of hidden files in $HOME makes sense as it will usually contain other stuff. Appdata contains no other stuff so if you're in there you want to see it. You might as well make /etc hidden or the whole NAND filesystem as, going these standards, no "normal" users have any business looking there either.

Perhaps you could compare it to the hidden $HOME/.config directory that people are trying to encourage then?
I'm not really sure what you mean by "if they're in it they want to see it", if they're in it they will see it. My point is to hide it when they're not.
And /etc and the NAND / are already "hidden" in the sense that the user won't see them unless they go looking, unlike pandora/ which is on their SD card.

EDIT: For reference, I'm suggesting ".pandora/appdata/" not "pandora/.appdata/"

 

[PokeParadox]

I don't mind either way about the appdata being hidden or not...
You just hit CTRL+H to see hidden stuff...

 

[dgame]

A simple zenity checkbox script would be a perfectly good short term menu/desktop item selector. (and I may yet write one)
It also allows people to select only the apps they want in PNDs with multiple apps.

...

Well I dislike multi-app PNDs to begin with. I think in general it is a bad idea. I mean what is the advantage? Maybe to save a few K for shared data? Not worth it. For example a VICE PND may include emulators for C64, Vic-20, Commodore plus 4, PET models, C128 etc. So now I have a big wad of dead icons with no supporting ROMs cluttering up my minimenu emu page and all I really care about is C64!

Same with Quake, it includes modules and icons for all kinds of paks. I only have one pak so now I have a bunch of icons cluttering my menu and most of them are dead. It sucks. It is a dumb idea and I can only se a couple of cases to use it. I mean if I have all of those modules what is the big deal having separate PNDs? I would then have the same amount of icons. It is dumb.

Hiding the appdata dir is a terrible idea though. What if (and this happens allot) I try an app, don't like it and delete it? I don't want a bunch of orphaned appdata directories full of crap hidden on my card!

+1

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

 

[cosam]

Perhaps you could compare it to the hidden $HOME/.config directory that people are trying to encourage then?

Yeah? Well I don't like that either ;-)

I don't get what the big deal is with having one measly directory visible, especially seeing as that directory contains important stuff which can be useful for installation and/or debugging purposes. I can see the posts already:

User: OK, I'll send you my save state so you can debug game X for emulator Y. Where can I find it?
Dev: On the SD card in /pandora/.appdata/emuY/saves/.
User: Um... I don't have that directory on my SD card.
Dev: Yes you do, it's hidden.
User: Hidden? How do I unhide it then?
Dev: Depends. Which OS are you using to read the card?

etc...

 

[Aninhumer]

I don't get what the big deal is with having one measly directory visible, especially seeing as that directory contains important stuff which can be useful for installation and/or debugging purposes. I can see the posts already:

User: OK, I'll send you my save state so you can debug game X for emulator Y. Where can I find it?
Dev: On the SD card in /pandora/.appdata/emuY/saves/.
...

I'd say the dev should either let the user set the save location, or include an "export save" feature (which is just a copy essentially).

(Also I meant ".pandora/appdata", although this doesn't really change your point.)

EDIT: And this is exactly my point.
By making this directory harder to get to, devs remember they shouldn't be putting saves in it.

 

[Loon]

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.

 

[cosam]

I'd say the dev should either let the user set the save location, or include an "export save" feature...

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...

...(which is just a copy essentially).

That rather depends. Not all apps have the means to ask get a path from user, so a file picker would need to be added in some cases. Seems like a lot of work in order to "protect" users from the evils of being able to see a directory (gasp).

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. Where else are we going to put all this stuff?

 

[sebt3]

Seems like a lot of work in order to "protect" users from the evils of being able to see a directory (gasp).

Loll