Ok I Tried The Whole Separate Appdata Dir Thing

[skeezix]

Dunny -- there is no putting appdata folder inside the pnd. ie: ITs like realtime writing to a zip file or video file in analogy -- its just not practical. You generalyl do not mount an iso read/write and random seek around to write into it. Hence, redirecting to somewhere else

Minimenu is still minimal; when the xfcve apps were added to it.. its just a single pnd file, that advertises out a pile of apps, that just so happen to already be there; when you run them, it doesn't have to fire up xfce or any madness, it just rns them like any other app. No changes to minimenu.

The changes to minimenu, the idea to be considered, of hiding files etc, is the same discussion that would come up over tiem when you have 5000 emus on your SD cards, so its a valid path of discussion (and one we all knew was coming -- I very carefully did not try to go too far ahead, as time is limited, but wanted to see where thigns were going and what peopel thought, before aiming the arrow; its best to aim in the right direction after figuring out the target

So minmimenu is about sytarting up very fast, and showing you what you want, and getting it up and going quick. set your wifi default to off, and its coming up fast.

Theres still more background processes and system gunk to remove (especially for minimenu mode), but thats not minimenu.. thats 'minimenu mode' in the firmware.

Question like -- minimenu is about running one app at a time, and hidding pandora button kills it to return to minimenu; if you run a windowed app, it'll work fine.. like the browser; but you still only get one app at a time, no multitasking. We _could_ add some way to switch apps and kill apps and such in minimenu, but then we're well on our way to turning it into a whole mini-DE, which is not where you want to go. (We could fork it, have minimenu for minimal environment,a nd minimenu for larger environment, as two separate and entirely valid goals, provided we dont' sacrifice the original goal of uber minimal.)
So you would see (if you had your pandora , that minimenu has no such facilities now -- its still much like a PSP, gp2x, gp32, etc -- it comes up, shows tyour apps, lets oyu pick one, or switch to another gui (or terminal so you cvan hack around a bit.) Thats it.

jeff

 

[skeezix]

An 'appdata cleaner' app is trivial to write (_trivial_, a very short sh-script even.) -- ie: just a bit dangerous if it removes data you wanted to keep.

I coudl see an app that shows a list of installed pnd files, with a checkbox beside them if they have a appdata dir; the orphaned appdata dirs woudl be plainly visible -- checkbox and unique-id, but no correspondinging app that owns them.

You coudl then pick an orphaned appdata and wipe it out, or move it somewhere, etc.

It'd be a pretty easy job to write up something -- hell, do it with python+qt or python+gtk or something, piece of cake.

jeff

For people who hate appdata -- remember that its pretty much how most systems do it; a PSP game is on UMD, and writes its appdata to memstick; a Windows app (I know, its _windows_, not to be considered a feature writes back to user homedir -- windows apps are nowadays discouraged or blocked from writing back to their program directory; Unix apps -- write to home dir, or to /var, etc. The separation of app data and application is a pretty common thing, its not like we invented that; we just came up with a clever way of doing it

 

[dflemstr]

OK, I'm at home now, should get that PXML template going soon, expect a new topic.

 

[WizardStan]

No, it's a requirement of the format that the PXML exist in the root of the ISO too.

http://pandorawiki.org/Libpnd_hub#File_format_-_.pnd_files

Huh. I wonder if that's why none of my PND files were working on Jeff's prototype. That's kind of a lame standard then that I would have strongly voiced concern against if I'd actually bothered to read the spec in its entirety instead of glancing over it

 

[skeezix]

The PXML being required in the root of the iso is 'for good form', not required by the system; if you go read up why, you'll note that its for ease of people who unpack and repack the pnd -- if you mount and cp everything, you want to kepe the PXML, right? If you just mount, cp, and delete the pnd, and the PXML is only appended, you've lost it.

So a PND, to me, is 'everything', and then you convert it into a .pnd-file, which just so happens to have the icon and PXML appended for convenience; but you still want them inside, so they're part of the PND package.

Agree or not, but I've tried ot put up some of the reasoning in the various documents

jeff

Wiz -- you had one or two that worked no, or did they only work when run from command line as normal? You probably had screwy lib dependancies or something that your reunscript in the pnd didn't address, or typos; I think one of your pnds you forgot the exec bit, or had a typo in the sh-script, or something, but I forget now. I think at the time we didn't even have /tmp/pndrun<id>.out to see the problem

 

[skeezix]

Back to Dave's original question -- I'll see if I can post a pnd_run.sh replacement (maybe a pnd to set it up), so you can see how it goes.

*pant pant*

I need ot get back to writing some of my games, the last coujple weeks have been way too much work

jeff

To be precise..

The system already searches subdirs, so you can put a pnd file in /pandora/menu/fooby/gop/ if you want.

So in that case, you would do something like..

/pandora/menu/emu/hatari/Hatari.pnd
-> system would create /pandora/menu/emu/hatari/hatari.skeezix for appdata
-> user is creating /pandora/menu/emu/hatari on their own, of course

Right?

 

[rick0815]

The PXML being required in the root of the iso is 'for good form', not required by the system; if you go read up why, you'll note that its for ease of people who unpack and repack the pnd -- if you mount and cp everything, you want to kepe the PXML, right? If you just mount, cp, and delete the pnd, and the PXML is only appended, you've lost it.

Uhh, does that mean that it is not impossible to have one version of a pxml appended to the pnd-file and accidentally a different version one within the pnd-file?

 

[skeezix]

ricki -- sure, course, just like you can name a file 'megaporn.doc' and fill it full of recipies; or to be precise -- at some point you have to trust the developers

jeff

 

[rick0815]

No offense. It's just good to know. If I, for any reason (I am that kind of person B) ), change something in a pxml it's good to know there is the original somewhere

 

[cosam]

No, it's a requirement of the format that the PXML exist in the root of the ISO too.

http://pandorawiki.org/Libpnd_hub#File_format_-_.pnd_files

Huh. I wonder if that's why none of my PND files were working on Jeff's prototype. That's kind of a lame standard then that I would have strongly voiced concern against if I'd actually bothered to read the spec in its entirety instead of glancing over it

I was also skeptical to start with but working with it you see the merits. For example, I find it easier to keep a directory per app when making packages, and just keep the PXML in there instead of having them all lying around in the parent. I then build the package from the parent, just a mkisofs/mksquashfs and a "cat" and you're done.

 

[laurencevde]

iso-read and unsquashfs already allow you to extract individual files from iso-s and squashfs-s, so (apart from some very minimal speed-reasons), why would you want to require appending stuff to the end as well? Seems like useless duplication to me...

And, as for the appdata-location, can you make sure that it's possible to use 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? Making sure that all other vars are defined in pnd_run.sh before the app's appdata-dir is, should be enough...
Oh, and shouldn't the locations be configurable in a separate configuration-file, instead of in the script itself?

But I think putting lots of app-data below the same directory as where the pnd-s reside, will slow down finding all pnd-s...
Some ways to fix that: tell libpnd to not look deeper than a few dirs; use a FS that can be traversed reasonably fast(f.ex: reiserfs); 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); don't look in dirs with a particular name; an extended attribute on dirs that tells libpnd to not look in that dir

 

[juniorm33]

iso-read and unsquashfs already allow you to extract individual files from iso-s and squashfs-s, so (apart from some very minimal speed-reasons), why would you want to require appending stuff to the end as well? Seems like useless duplication to me...

As you said I believe it was speed reasons, I'm not sure how much faster it is, but it could be one of those situations where it really adds up with things that need all the PXML's, eg menu systems/lauchers.

 

[SomeGuy99]

We _could_ add some way to switch apps and kill apps and such in minimenu, but then we're well on our way to turning it into a whole mini-DE, which is not where you want to go. (We could fork it, have minimenu for minimal environment,a nd minimenu for larger environment, as two separate and entirely valid goals, provided we dont' sacrifice the original goal of uber minimal.)

In minimenu I fire up a terminal and run multiple apps from there (alt-tabbing between them).

My idea for XFCE: right click 'move to menu' or 'move to desktop'.

 

[Esn]

A right-click option to display the documentation and the appdata folder name would be nice addition

Couldnt it just scan to see if the pnd related to an appdata exists, and if it doesnt, ask(once) if it should be removed? Or, have a right click option to uninstal pnds, that would remove+unmount the pnd, and ask if you want the appdata removed?

Those seem like they could be good ideas to me, though I haven't received my system yet...

 

[Pleng]

My idea for XFCE: right click 'move to menu' or 'move to desktop'.

It might be nice if the default browsers would recognize PND files as they're downloaded from the appstore and replace the standard file download dialogue with one that prompts you for which SD card you'd like to save the application to, and asks you if you want the icon to appear in the desktop, on the menu, or both.

 

[mindlord]

My idea for XFCE: right click 'move to menu' or 'move to desktop'.

It might be nice if the default browsers would recognize PND files as they're downloaded from the appstore and replace the standard file download dialogue with one that prompts you for which SD card you'd like to save the application to, and asks you if you want the icon to appear in the desktop, on the menu, or both.

Sounds like a Zenity script waiting to be written.

 

[DaveC]

We could make an option so the appdata dir for an app is in the same place as the app.

The reason thids was not done was -- if a user sticks the app into /pandora/desktop, and then moves it to /pandora/menu, he has to mvoe the appdata dir too. You also run into the confusion of .. "wheres mny appdata?" - it moving around wherever the app has to be.

Theres really a couple ways to do it -- the way we do it now (well defined single location), doing it with the app, or some others; we figured at first, it is best to pick a well defined simple method and see how it goes.

To change the appdata dir location, is a change to pnd_run.sh and thats it -- no extra work, just one place, in a text sh-script, in I think one line; so not hard ot alter and experiment, if folks wouidl like to see how it pans out.

jeff

Well I have my pnds in their own subdir anyway. I do this because I also have my ROM dir, override icon, override preview pic and override text file for title names and notes in this spot. If the app data dir was in there too then it would all be together in that one directory for that app. That would be pretty simple to me. I would not have to guess what is what or which app data dir goes with which version of app etc.. I use mini menu so I don't know if that matters. Minimenu finds the pnds in their subdir in the menu directory now fine. There should at least be an OPTION to do it like this.

 

[skeezix]

Davec -- no time to hack it out today; it looks like a 3 or 4 line script change, pretty easy.

Maybe I'll have time tomorrow, but pretty busy right now

Ajnyone else, feel free to hack pnd_run.sh (seems like so far theres only a few of us who know the internals, so we're a vector for every request every person can think of, its keeping us busy for sure

Vimacs.. where are you?!

jeff

 

[mindlord]

What would happen if you made this:

<application id="exaile" appdata="exaile">

read like this in the override .pxml file?:

<application id="exaile" appdata="../menu/exaile">

Would that not make the script back out of '/pandora/appdata' and then traverse back up the tree to '/pandora/menu/exile/' ?

 

[DaveC]

To be precise..

The system already searches subdirs, so you can put a pnd file in /pandora/menu/fooby/gop/ if you want.

So in that case, you would do something like..

/pandora/menu/emu/hatari/Hatari.pnd
-> system would create /pandora/menu/emu/hatari/hatari.skeezix for appdata
-> user is creating /pandora/menu/emu/hatari on their own, of course

Right?

How do you get it to do this? Right now all I see is the system creating /pandora/menu/hahatari.skeezix for appdata.

Right now I have /pandora/menu/hatari.

And in Hatari dir I have:
/ROMs
Hatari.pnd
Hatari.ovl
Hatari.png
Hatari_pvw#0.png
And would like to also have in there:
/hatari.skeezix - for appdata.

This way all my hatari specific stuff is in the same dir.

Couldn't the pnd just look in two spots for that appdata dir automatically? It would normally create the appdata where it does now when first run so nothing changes. So those that love this can keep it. If users like me don't like that we could move the system created appdata into the same subdir as the app like above. Since it looks in both places if it doesn't find it in the usual spot it will look in the app's dir.

Obviously I would prefer it FIRST creating the appdir in the app's dir, but since more seem to like it better as is now for some reason I would have to compromise.