Pandora Pnd File Dependency Checker Ideas

[Pickle]

The whole debate about user usability, frontends, updaters, backends gave me a few ideas, some of which are already in the works. One problem that is something that is a common issue for new users is the file management of files that are critical to run the application. Its been a problem with any of the consoles, how many threads have there been 'where and what files do i need to run quake'

The problem has come up a little bit in the other discussions and the quick and dirty solution is to have the run script in the pnd check during runtime and spit out some message.
But this is pretty crude and ugly and i think it can be better.

My current idea is to have a path relative to the appdata folder and a list of filenames in the PXML. libpnd uses this data and checks for files in the list. libpnd then on request sends information back to the clients apps if the game has met the requirements or not. The client then by some GUI (icons or something) identifies to the user that the app wont run as installed.
There could also be some mechanism for the client app to explain in detail what is missing and where to put it.

First step would be to define and add support in the pxml and the checker in libpnd with a simple interface to query pass or fail.

Thoughts, flames?

 

[skeezix]

Minimenu could do it; no real slow down, since might onyl do it just when user hits 'run', so its not scanning for all apps at once.. just the current app (or maybe current app until it passes, then not look at all.)

For xfce what woudl you want to do .. change the .desktop so that instead of running the app, it runs a pre-run app which in turn runs the app after doing checks?

I'm on the fence -- the app packagers is the subject matter expert so could create as simple or complex a up-front-check as they like, and pop up a zenity script.

PRoblem with that ..
i) some devs are lazy
ii) some packagers are just doing quick ports or script for an existing build, so they're not too hardcore scripter
iii) inconsistent UI -- each dev making their own check (if at all) and their own popup using zenity/QT/SDL/whatever .. not "pretty".

Putting it into PXML would make it easier for the dev, and more consistent UI.

Implication..

1) For 'easy' dependancies, this would work
2) For 'complex' ones (if its "this bio,s OR this one, OR that one...") then dev woudl have to do something anyway, and we know most devs are lazy :/

Question ..

We've skirted around the heavier duty 'dependancy' system; this pnd depends on that pnd, for instance, since thats sort of hard. (pnd depends on pnd, which in turn depends on pnd .... do you end up mountign 10 pnds to load one app? thats why we push for self contained single pnd, so its all in there, one mount and go, cartridge style.)

So we could try to do this as a a heavier pnd-dependancy thing .. depend on other pnd, or depend on file existance.

So if we put it to PXML, we could maybe spec out a heavier solution, even if we don't implement it all yet and just go for file existance check.

--

*shrug*

jeff

 

[WizardStan]

I see where this is going, but is it necessary, and is it easy?
In jzintv I did this in the startup script: it checks for grom.bin and exec.bin; if it can't find them, it prompts the user to find them. So it's not necessarily difficult for applications to right now do something similar.
On the other hand, putting it in libpnd would give a consistent look and feel: if some new file is suddenly needed, it's simple to just add to the PXML and libpnd will take care of it in the same way it takes care of the rest.
On the other other hand, consider something more complex, like PSXReARMed. It doesn't need a bios file, but the bios file definitely makes the experience a lot better. But there's, like, a dozen different bios files, and really any one of them will do (although some work better than others). You'd have to find the bios file, one of a dozen different possible names, and then add it to the config file. Is there an easy, generic way to do that? Alternatively, don't bother with this kind of case: just solve the general case of static data files that are missing, and let the rare application with very specific needs handle them itself in the startup script.
Hmmm... could work.

edit: *gasp* h34r:

 

[Pickle]

Ok for the generic cases, maybe the list contains *.zip, if you have any zip at location X it passes the test. Most cases the user doesnt even know to put any zip at location X.

 

[sebt3]

Minimenu could do it; no real slow down, since might onyl do it just when user hits 'run', so its not scanning for all apps at once.. just the current app (or maybe current app until it passes, then not look at all.)

For xfce what woudl you want to do .. change the .desktop so that instead of running the app, it runs a pre-run app which in turn runs the app after doing checks?

pnd_run.sh could host the feature. I just need a file with 1 dependency on each line. use | to mark different alternative. See :

bios/gba_bios.bin | bios/phew1000.dat
data/pak1.pak
data/pak2.pak
data/pak3.pak

Have this file referenced in the PXML and its path passed to pnd_run.sh and, done

We've skirted around the heavier duty 'dependancy' system; this pnd depends on that pnd, for instance, since thats sort of hard. (pnd depends on pnd, which in turn depends on pnd .... do you end up mountign 10 pnds to load one app? thats why we push for self contained single pnd, so its all in there, one mount and go, cartridge style.)

This is way different to my idea of PND-deps... I've yet to come up with something for this.

 

[skeezix]

For pnd-to-pnd deps, the trick is reference counting or lsof-checks or something, so that a depend pnd gets unmounted at the right time.

ie:

app1 and app2 both depend on pndA

pnd1 or pnd2 run, check for pndA already mounted (/mnt/utmp/pnd-a-unique-id) (not sure if we need a feature where pndA can mount its contents into /usr/lib, or if the pnd1/2 apps are built to look in /mnt/utmp/pnd-a-unique-id/ for libs using --Xlinker tricks.)

If pnd1 is run, then pnd2, and then pnd1 exits, pnd1's exit can't unmount pndA, but pnd2's can.

A 'file exist' dependancy would just be as you say ..

<dependancy>
<fileExistance>
<file>./foo/file1.txt</file>
</fileExistance>
<pndlib>
<pnd>foo-package-id</pnd>
</pndlib>
</dependancy>

Something like that....

jeff

 

[Schnatterplatsch]

I'm highly intressted in this topic.

I wanted to write something, but it seems the most important has been said already. So, would it be the easiest way to implemented this as a "before-run" check based on a "dependecies.xml" or special data in the pxml?!?
That way the data could be located and moved/copied by std dialogs without having to deal with SDL or whatever the app uses to run, right?



So, then we just would have to define a specification how that xml would have to look like and this may be ready before HF6

 

[Alec]

app1 and app2 both depend on pndA

pnd1 or pnd2 run, check for pndA already mounted (/mnt/utmp/pnd-a-unique-id) (not sure if we need a feature where pndA can mount its contents into /usr/lib, or if the pnd1/2 apps are built to look in /mnt/utmp/pnd-a-unique-id/ for libs using --Xlinker tricks.)

If pnd1 is run, then pnd2, and then pnd1 exits, pnd1's exit can't unmount pndA, but pnd2's can.

A 'file exist' dependancy would just be as you say ..

<dependancy>
<fileExistance>
<file>./foo/file1.txt</file>
</fileExistance>
<pndlib>
<pnd>foo-package-id</pnd>
</pndlib>
</dependancy>

Something like that....

Inter-PND dependency sounds like a terrible idea to me.

This is going to end up as a re-invention of a package-manager, except that we don't have a canonical centralized repository nor do we have QA that has the responsibility to ensure that everything is working well with everything else. This will lead to all sorts of badness.

As a simple hypothetical example, let's suppose we have an MPlayer PND and an SMPlayer PND (a gui to mplayer). What would happen if:
- MPlayer breaks ABI, the available version of SMPlayer is not updated?
- SMPlayer is in Slot1, MPlayer is in Slot2, and then the card in Slot2 is taken out?
In both cases, the problem would be pretty non-obvious and frustrating to the users.

If two applications depend on each other, they need to be packaged together to ensure that they work. If you need to do dependencies, then a proper package manager should be used.

 

[torpor]

Instead of having all this to roll out, instead why not add a diagfs-like interface to the PND manager whereby, if an app accesses a file that is not 'on' the filesystem, inotify()'ication happens in PND manager, which then opens a browser to app-defined URL/howto about the filesystem setup?

So PND writers can define files they expect to be in place in a filesystem, and if they're not there, PND figures it out and pops up the browser. When a PND is open, the list of 'expected files' is built, PND checks if they're there, case a: they're there, ignore, case b: create a diagfs/notification on the files, so that when the user does something with the PND, instead of opening the files, the browser pops up to the PND-info page explaining what files need to go where.