Pandora Idea: automatic wrapper scripts for PNDs in /usr/bin


_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,390
Age
42
Location
Brussels, Belgium
Perhaps someone else also had this idea, but I haven't seen it yet so I'll start this thread anyway.


Currently, when a PND is found, it will be automagically added to the menu and/or the desktop. Why not add to this a wrapper script in /usr/bin/, simply a bash script with the name of the main executable, that calls pnd_run and passes the arguments. So e.g. if you have the tuxpaint PND, then /usr/bin/tuxpaint will actually run the PND for you. This would be nice when using the terminal (so I can type "mc" in a terminal to get Midnight Commander, etc.), but it would also make it much easier for PND's to use one another.


Some other directory that is in $PATH would probably be OK too, but I'd prefer /usr/bin since that is the default spot and some applications might ignore $PATH and just look there. Of course this requires the automagic script adding thing to be able to write there.


When the SD card goes away, the script could be removed with it, or it could be kept and it should check whether the PND is still there - if not, it can display some kind of message telling you to insert a SD card containing that PND.


The cleanest way to do this would probably be to add something to the PXML format so applications can specify the name of the wrapper script to be added.


What do you think?
 
It shoudn't be /usr/bin, that'd be asking for trouble (imagine the amount of crap that can build up.) I suggest something like /tmp/bin and adding that to the users path.


If the app doesn't use $PATH and instead uses hardcoded paths, then it's not worthy using.
 
That's a really nice idea... Though, I think you can make it even easier. I'm not 100% Linux, so I might get a few of the technicals wrong, but from Sebt3's VM, you can "set" environment commands like environment variables...


Sooo... Tweak the pnd discovery daemon so it adds to the bash/sh environment functions PND names (minus the .pnd extension), calling "pnd_run <pnd path>" which can be filled whilst creating the .desktop files etc.


I'm not sure if you can set shell environments outside of the shell (somebody more Linux would have to tell me), so you might have to put it in the shell startup (assuming there is one) instead of the PND daemon


Edit: You could actually make the command that it maps too part of the PXML as well. So you could get "xcom_terror_from_the_deep.pnd" to map to "tftd" instead, for example.


Or maybe even have a configuration UI, that says "PND's with this name map to this shell command", then you can also disable some.


Edit 2: Just heard from ED, apparently my Pandora's going to be ready in a few more days. If somebody wants to point me in the right direction, I'll probably have a look at this when I get it back
 
Last edited by a moderator:
I've mentioned in the past a way to do it..


Goal: just run a pnd from the command line, easily.


How.. well, we already havbe pnd_run to do it, but that might make you guess which sub-app it is.


We already have .desktop files, but most distros don't make those purely executable, otherwise you could just add /usr/share/applications and ~/Desktop to your $PATH and be done with.


So really, a 3 line sh-script ("desktop-run" or whatever) would be all thats needed, to grep out the Exec= line and invoke it, from the named .desktop file. The arguments would be .. either a fully qualified path to the .desktop (no ambiguity) or just the pnd-name or something, and the script coudl grep and guess which you mean.. ie: if you put 'desktoprun mame' theres a good chance it coudl match 5 different pnds, so it'd have to error out and ask for more specific keywords. Or you could say 'desktoprun ~/Desktop/mame4all.desktop' and good to go.


Actually having the apps show up in your path .. could add an option to pndnotifyd so that it would emit /tmp/bin/FOO where FOO is a symlink to desktoprun perhaps, and then desktop run makes a guess based on the filename (could use the unique-id but they're often nonsensicle.)


Could modify PXML spec to allow a simple command alias to be named, and then have pndnotifyd emit _those_, but then it'd take years for all existing apps to get updated.


I rather prefer a simple change.. include 'desktoprun' (a trivial script to write) and no changed to pndnotifyd or PXML specs .. just somethign equivilent to pndrun but for .desktop files.


jeff


edit: I suppose appdata-name in PXML is usually not too wacky, so could perhaps have an option that when enabled, emits to /tmp/bin/mame4all and then that symlinks back to desktoprun (say.)


(Could just emit a separate script for each app, but you then run th risk of emitting 1000 small nearly identical scripts, which eats up a lot of RAM possibly. I figure symlinking means one script, and fast tiny symlinks.)
 
Last edited by a moderator:
Someone check if we include xdg-open anyway..


That used to work years ago, in various distros, but has been flaky for a long time .. but if we include it, it may just work. (Just like xdg- ways to open a browsder and other 'preferred apps'.)


IF xdg-open is there, it may well just take care of things..
 
Thanks for your input on this. As usual, I was looking to over-kill :) When I get my pandora back, I'll look into the desktoprun script


Cheers
 
The canonicle old way of doing this is:


#!/bin/sh


`grep '^Exec' $1 | tail -1 | sed 's/^Exec=//' | sed 's/%.//'`


ie: Look for Exec - discard the "Exec=" part, and go. (Theres a tail -1 in there in case of multiple apps in one .desktop, which shouldn't happen for a .pnd file though. Also, theres some stuff to drop arguments fro the Esxec-line, which also shouldn't happen in pnd-files, so we could strip it to just..)


#!/bin/sh


`grep '^Exec' $1 | sed 's/^Exec=//' `


That'd probably do it, but I'd rather have some erorr handling.


Likewise, sewarching for keywords across multiple files and handling multiple matching .desktops and so on, but thats the core of it :)


jeff
 
So really, a 3 line sh-script ("desktop-run" or whatever) would be all thats needed, to grep out the Exec= line and invoke it, from the named .desktop file. The arguments would be .. either a fully qualified path to the .desktop (no ambiguity) or just the pnd-name or something, and the script coudl grep and guess which you mean.. ie: if you put 'desktoprun mame' theres a good chance it coudl match 5 different pnds, so it'd have to error out and ask for more specific keywords. Or you could say 'desktoprun ~/Desktop/mame4all.desktop' and good to go.

Ah, now I'm home and reread that, how's that any different from calling "pnd_run /media/mmcblk0p1/gedit.pnd"?


What we were after is just typing "gedit", and it'd effectively run the full pnd_run command.


In sebt3's VM, if I type set, I get things like



Code:
quote ()

{

    echo \'${1//\'/\'\\\'\'}\'

}

Where if I type "quote" in the command line, it prints me two quote characters. So my plan is to set these (as soon as I can find out how you do it) per PND (maybe configured by some GUI)

Would this be able to take care of file associations too? This is another area where I feel Pandora currently falls short.
I'm not sure exactly how file associations work in Linux, but maybe. I'm currently playing in the VM, and we'll see
 
pnd-run has to be told the subapp number for >1 app in a pnd; the .desktops are emitted per executable, so there would be no issue there (ie: less confusion.)


My point for desktoprun was that desktoprun woudl run the .desktop, and then you use symlinks or the like to associate a common name to /tmp/bin .. the harder part is getting a useful command name, since the unique-id is often gibberish .. we coudl try the appdata dir name.


So ..


1) write up desktoprun


- it has to know how to run the Exec= line, as above


- it shoudl take two kidns of argument itself..


- 1) a full path to a .desktop, whcih makes it easy


- 2) A appdata dir name, where it then tries to find the matching .desktop in /usr/share/applications and ~/Desktop


-> then run the app found in (1) or (2)


2) Then I can modify pndnotifyd to emit symlinks from /tmp/bin/mame4all to /usr/pandora/scripts/desktoprun


User opens shell, and has /tmp/bin in their $PATH


You type 'mame4all' and /tmp/bin/mame4all is a symlink to desktoprun


desktoprun checks $0 and sees it is being called 'mame4all' and then goes looking for mame4all in /usr/share/applications and ~/Desktop and runs it


jeff
 
File Associations .. I shoudl add that again, thanks for reminding


Theres a few ways to do it depending on the type of desktop, but assuming a freedesktop setup liike we're doing now, then it is essentially adding some entries to the .desktop


(There are other ways, such as injecting file sinto the master repository, but a .desktop entry can do it too, which makes sense for us, since .desktop is gneerated from PXML anyway, and PXML includes the file association requests if any.)


Example:


For the gimp:


MimeType=application/postscript;application/pdf;image/bmp;image/g3fax;image/gif;image/x-fits;image/pcx;image/x-portable-anymap;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-psd;image/x-sgi;image/x-tga;image/x-xbitmap;image/x-xwindowdump;image/x-xcf;image/x-compressed-xcf;image/tiff;image/jpeg;image/x-psp;image/png;image/x-icon;image/x-xpixmap;image/svg+xml;application/pdf;image/x-wmf


The PXML spec we defined is:


<associations>


<association name="Deinterlaced Bitmap Image" filetype="image/bmp" exec="-f %s --no-deinterlacing"/>


<association name="Style sheet system crasher" filetype="text/css" exec="-f %s --crash-on-success"/>


</associations>


We didn't real hammer down the paramter details I think (I forget, my memory is no good since the twins born :) -- but for most apps its just APPNAME ARGNAME, but the Exec= line has some params possible, should be easy.


--


Would be work to add to minimenu, but really, minimenu doesn't really get used much for browsing random files, its mostly a launcher (very few people use the dir browser panels.)


--


If folks want, I can look into file associations again.. I'd left it, since at the time I was building a lot of this stuff it was of lesser import.. but I suppose a couple years has gone by now :)


jeff

 
pnd-run has to be told the subapp number for >1 app in a pnd; the .desktops are emitted per executable, so there would be no issue there (ie: less confusion.)
Ah, right, I understand now.


Out of curiousity. Could you just just drop a "mame4all" script which has the same execute statement as the .desktop file into /tmp/bin? That would mean you wouldn't need to worry about parsing the .desktop file?

My point for desktoprun was that desktoprun woudl run the .desktop, and then you use symlinks or the like to associate a common name to /tmp/bin ..
Yep, I'm afraid you have to be a bit more obvious with me, because I'm still quite slow on the Linux thing ^_^

the harder part is getting a useful command name, since the unique-id is often gibberish .. we coudl try the appdata dir name.
That was why I was thinking of PXML and/or some sort of configuration app. It also means users can control their own names. Could we use overlay files to help with this? Do overlays allow adding additional data?
 
PXML change would do, but my concern (noted up :) is that it'd be a long time for a lot of apps to get updated. (Especially since demand for this would likely be pretty low.. most peopel would use xfce or minimenu or other desktops, but not invoke stuff like mame from the shell. A few apps are rather shell-centric so would get more use that way, such as ncftp or emacs or gcc or whatever.)


Really, a PXML approach would be _best_, if we can get devs to update their pnds. ie: Say you want to package up gcc .. a common approach is people have it pop open an xterm/whtaveer with the environment all set up (LD_LIBRARTY_PATH, PATH, overlays, etc), which is peachy for running from a desktop; but if you wanted to run it from your own shell, .. its a big mess to do it like that. (Mind you, the approach above is also pretty poor .. mount/run/unmount for every build step is going to be suicide... what you'd really do there is mount, use/use/use/use/unmount, but thats not being address above .. this scenario is why we didn't act on it long ago, since getting to the 'real meat of it' is hard ;)


But if you 'just want' to have pnds show up in /tmp/bin or whatever, can be done .. just a matter of how extreme.. a minimal change, or go all the way with PXML etc, and require devs to do stuff.


..


FWIW, I was figuring symlink magic which is a litytle goofy, but means les RAM used up (/tmp is in RAM, so creating 1000 identical little scripts takes more time/space than just creating a stack of symlinks.)


So we can do _something_, but exactly what and how far is to be determined.


Should really slide this over to the mailing list or post a link to this thread there, to get a few more people's comment.


--


Options..


For getting plain pnd showing up in shell paths..


i) minimal effort: emit all apps (by appdata name) to XXX/bin using a emitted script/symlink .. change to libpnd/daemons needed, but trivial stuff.


ii) more effort: add to PXML spec so app devs can define which subapps to stuff into shell paths and how to name them <- not hard, but need to then bug devs to update their pnds as appropriate <-- may be the best way to do this, since we're not talking every app, just a few. So work this angle...


iii) maxium work .. handling of long lived apps, such as gcc, where you really wane to invoke it many times, but mount/runm/unmount cycle per invocation is slow


iv) even more work! .. handling nonexecutables.. long lived shared libs and datafiles and such ... dependancies between pnds? on first run of XX, leave the mount open if PXML flagged?


These are hard questions, which is why we didn't progress.. but perhas we should biute off the easier bits :p


Sorry for spelling, in a meeting..
 
Sorry for spelling, in a meeting..

I take it that it's not a very important meeting ^_^


Going to post it in the mailing list now.


Edit, for my purposes, I might just add something to my .bashrc file. As you mentioned, you're not going to necessarily want to do this for every single PND. Most likely applications of some variety (Graphics packages etc.).


Also, you'd need to be careful of collisions between PNDs... Say two packages both expose the same app (but as a different collection, I believe there are several copies of XTree in a few PNDs), how would you resolve that?
 
Last edited by a moderator:
Oh, its going to be inelegant at some level -- the whole system relies on 'reasonably unique'; we dont' want a unique-id assignment web app so peopel can reserve unique0-ids or that bullshit, so we make it 'reasomably unique'.. put your name in there, good to go.


Then people assign 'appdata' name, and theres more risk of collision there.. say, if everyone calls their app 'mame'; so we define the system so as the 'behaviour is undefined' in that event, but in practice.. if 10 mames all use the same appdir, theres a decent chance they'll work anyway ;)


But then you add another layer for problems.. letting peopel specify the 'convenience shell name'; so evne if mame4all-notaz-12345 unique-id has appdata 'mame4all', what if 37 peopel make all their mames have a shell naem of 'mame'. Collision.


Really, the only workaround is peopel to use 'mame4all-notaz' as their executable name; its clumsy, but shoudl work. But we leave it up to the pnd packagers and say 'we want it reasomably unique'.


And then when we code it, we handle it as best we can .. we either skip if we see a dupe, or we overwrite; we just canm't explode in a ball of fire, is all :)


.. So I don't sweat that sort of thing.


--


No, I sweat the later stuff .. the hard stuff mentioned above; if we make pnd with dependancies (so you can say mypnd depends on wizstans java pnd).. hwo do we define it? how does it work? does one pnd depend on another, which in turn depend son another, and they all get mounted at once? How long do the dependants stay ounted for?


*bleh*


--


Thats the hard stuff.. thats been holding us back for quite some time :)


jeff
 
Wow, nice to see that there has been some interesting discussion in this thread. Some comments:


I wouldn't go too far with the PND dependency stuff, because it gets complicated very fast. Just a "weak" dependency of the kind that one PND calls some external program (say gedit), which may actually reside in some other PND or not, but this is transparent to the caller (hence the need to have something called "gedit" in the PATH, be it the actual executable, some symlink, or some script).


Using the appdata as a name could be a good approximation to avoid the problem of having to update the PNDs, but I can imagine situations where this would not work. For example, there is "mc" (midnight commander) which has its own editor "cedit". The PND packager did not bother to specify "cedit" as a separate application, but if he did, it would probably have the same appdata dir as "mc". Similarly, a PND for gcc may include several other utilities (e.g. "make"), but they don't need their a separate appdata dir.


Instead of requiring PND packagers to give the information, we could also manually but in a centralized way maintain a list of PNDs and the command names they provide - and then e.g. make sure that the PNDManager updates this list. Then when the user types "gedit", the PND gets called if he has it, and if he doesn't have it, we could even display a helpful message saying "Please install the following PND: ...." (much like some distributions currently do when you type a command it doesn't know)


An important thing is that command line arguments need to be passed, so I can type "gedit <filename>" and it just works. Or does pnd_run already support that?


About the mount/unmount overhead: the example of gcc is a good one, it would be insane to compile anything large by mounting/unmounting the PND at every invocation of gcc. Perhaps a pragmatic solution would be to add a timer: only unmount after N seconds (with a default setting of, say, 10 seconds, and changeable in the PXML). If it gets called again before it was unmounted, the overhead can be avoided. At least in the gcc case this would work, since there is almost no time between calls. The user might not even notice such a change in default behavior - if anything, it will improve things (e.g. if you quit a game and then change your mind and start it again).
 
In terms of a 'run .desktop' script we already have that in a sense in the existing PND_utils package. When installed it not only creates mime file associations allowing you to (for example) launch PNDs by double clicking them in Thunar, it also installs a script called pqr (pndquickrun) to NAND which will run the first app in a PND.


Just now for example, I was able to launch the firefox PND by typing 'pqr firefox'



Code:
op-inigo:~$ pqr

!!! ------------------------------- !!!

called '/usr/bin/pqr '

=-=-=- This script require at least 1 argument. make sure you specified which pnd to run. -=-=-=

Usage: pqr pndname [execfile]


pndname:

  base name of the pnd to look for. Case Sensitive.(will run the first pnd containing that string in the name) (eg: PanPlayer would match PanPlayer.pnd or PanPlayer-r10.pnd)

  if the file exist (full path relative or absolute), it will use it instead of searching


execfile:

  optional, when specified, will run said file in the pnd instead of the default one. (needed for panplayer with avi, since default launch picklelauncher)

op-inigo:~$


op-inigo:~$ pqr firefox

!!! ------------------------------- !!!

called '/usr/bin/pqr firefox'

pndfilepath:'/media/PND-DATA/pandora/apps/firefox-13.0-1.pnd'

execscript:''

running: pnd_run "/media/PND-DATA/pandora/apps/firefox-13.0-1.pnd"

-----

Runscript	/usr/pandora/scripts/pnd_run.sh

Pndfile		/media/PND-DATA/pandora/apps/firefox-13.0-1.pnd

Subapp Number	0

Invoking: 'Firefox 13.0'

--

Mount the PND														[SUCCESS]

Starting the application (firefox.sh )							   [SUCCESS]

Restoring the frame buffer status									[SUCCESS]

uMount the PND													   [SUCCESS]

op-inigo:~$


What I'd be much more interested in seeing is an extension of libpnd and the PXML specs to allow PND developers to specify an optional command line invocation at the application level. As for how this would work, the system Skeezix recently described on the firmware dev mailing list would seem to fit the bill quite nicely.


To my mind, that the existing PND database doesn't take advantage of this so far unimplemented system and most PNDs are unlikely to be updated to do so, actually doesn't matter at all, as that really isn't point of implementing the system.


- Neelix
 
Last edited by a moderator:
Back
Top