-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi everybody! Considering that HF7 will bring some lovely new features (like Notaz libSDL with hardware acceleration for some areas) it might make sense to finally make use of the "osversion" feature provided in the PXML specs. This one is even more important once we think about the "eventually to be done" .next firmware where libs might even be bumped and incompatible stuff might be added.
For the Snes9x4p emulator I wanted to have a way to check if Notaz libSDL was already available on the system and Notaz told me that the best way would be checking for the firmware version since there is no clear way to do so just with the lib. Because of this I wrote a small shellscript extracting the version of the OpenPandora OS used (regarding /etc/op-version). I attached the script to this mail (cf the file "version_check.sh").
It might make sense to add something like this in pnd_run.sh and check if a specified osversion is actually met. If this is not the case I'd personally welcome some zenity dialog stating that the pnd requires a more recent firmware than available. In this dialog the user could be given the option to try anyway or to just abort. This should be a rather simple addition to pnd_run.sh since Cloudef today also mentioned some code to extract the version number out of a pnd while chatting in IRC:
strings youtube-dl.pnd | grep osversion | sed -e 's/.*major="(.*)" minor="(.*)" release="(.*)" build="(.*)".*/\1.\2.\3.\4/'
Personally I'd start the call with a grep to first see if osversion is specified and afterwards get the version, but that is just a tiny detail.
To make all this work in a sane way a slight change was committed to the PXML schema enforcing that the version numbers used with major, minor, release and build are actually "non negative integer" values. The PXML_schema.xsd, PXML spec documentation in the wiki as well as my toolchain installer have been updated. So far I don't know of any program setting an osversion which is *not* 1.0.0.0 if osversion is defined at all so this change should not break any existing apps (especially since so far there was simply no support for osversion anyway).
So what would be required now? Basically some change/addition in pnd_run.sh adding some code (eg reusing the stuff I attached to the mail) to compare version numbers and possibly display a zenity warning dialog that version requirements are not met.
Comments?
Cheers, Nils Kneuper aka Ivanovic
2012/2/23 Nils Kneuper crazy-ivanovic@gmx.net
strings youtube-dl.pnd | grep osversion | sed -e 's/.*major="(.*)" minor="(.*)" release="(.*)" build="(.*)".*/\1.\2.\3.\4/'
This wont work depending on the syntax used by the dev : <osversion major=1 minor=0 release=7 /> is valid as far as XML is concern, but wont be parsed by this command. You need to actually change libPND so it will provide that information to pnd_run.sh.
And then, what should pnd_run.sh do with that ?
On Thu, 23 Feb 2012, Sébastien Huss wrote:
# # 2012/2/23 Nils Kneuper crazy-ivanovic@gmx.net # strings youtube-dl.pnd | grep osversion | sed -e 's/.*major="(.*)" # minor="(.*)" release="(.*)" build="(.*)".*/\1.\2.\3.\4/' # # This wont work depending on the syntax used by the dev : # <osversion # major=1 # minor=0 # release=7 /> # is valid as far as XML is concern, but wont be parsed by this command. You need to actually change libPND so it will provide that information to pnd_run.sh. # # And then, what should pnd_run.sh do with that ?
Also, "strings" is pretty ineficient (considering a pnd could be 500MB in size, say :) -- though perhaps a binary 'tail' piping to 'strings' would do it pretty quickly
An idea I had awhile back was to just not emit the application during discovery if the OS version is no good, or perhaps not spit out an executable; but thats taking it too far. (I had thought perhaps of a popup warning box somehow, or a panel in minimenu, to list off such warnings.)
But heres an idea instead -- the returned application or emitted .desktop could contain an invocation of a wrapper script (say), that would pop up zenity or whatever warning and then in turn possibly run pnd_run.sh proper; ie: pushing the effort to up front during discovery (which is already done and has parsed PXML) rather than burdening every app launch?
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 23.02.2012 23:18, schrieb skeezix:
But heres an idea instead -- the returned application or emitted .desktop could contain an invocation of a wrapper script (say), that would pop up zenity or whatever warning and then in turn possibly run pnd_run.sh proper; ie: pushing the effort to up front during discovery (which is already done and has parsed PXML) rather than burdening every app launch?
Which is problematic with eg the new kernel. After a suspend to ram all apps are rescanned. Now imagine one old "test prog" that a user almost forgot about leading to those messages after every scan. IMO it is more sane to only issue the warning when a user tries to launch the application. The best way for this is probably storing the information in a file which is parsed/used by pnd_run.sh meaning the generated .desktop files. Just store the version in there and eg grep for the correct entries in the commented out area.
Eg we could add this at the end of each .desktop file:
# automatically extracted OS version requirement information: # REQUIRED_OS_MAJOR=1 # REQUIRED_OS_MINOR=7 # REQUIRED_OS_RELEASE=0 # REQUIRED_OS_BUILD=0
In pnd_run.sh we could simply grep using these terms:
grep "REQUIRED_OS_MAJOR" application.desktop | cut -d "=" -f2 grep "REQUIRED_OS_MINOR" application.desktop | cut -d "=" -f2 grep "REQUIRED_OS_RELEASE" application.desktop | cut -d "=" -f2 grep "REQUIRED_OS_BUILD" application.desktop | cut -d "=" -f2
In case there is some error for one of the fields of osversion either set it to '0' or don't extract the os version requirement stuff into the .desktop file at all.
Cheers, Nils Kneuper aka Ivanovic
On Thu, 23 Feb 2012, Nils Kneuper wrote:
# > But heres an idea instead -- the returned application or emitted .desktop # > could contain an invocation of a wrapper script (say), that would pop up # > zenity or whatever warning and then in turn possibly run pnd_run.sh proper; # > ie: pushing the effort to up front during discovery (which is already done # > and has parsed PXML) rather than burdening every app launch? # # Which is problematic with eg the new kernel. After a suspend to ram all apps # are rescanned. Now imagine one old "test prog" that a user almost forgot about # leading to those messages after every scan. IMO it is more sane to only issue # the warning when a user tries to launch the application. The best way for this # is probably storing the information in a file which is parsed/used by # pnd_run.sh meaning the generated .desktop files. Just store the version in # there and eg grep for the correct entries in the commented out area.
You misinterpret --
pndnotifyd rescans, and fills the Exec= line in the .desktop with a pnd_run_warning.sh instead of pnd_run.sh
Then when the user runs one of the 'old' apps, the warning comes up, and pnd_runm_warning.sh then runs pnd_run.sh with the same args, and everything goes.
ie: Easy change, no speed hit, just works ;)
# Eg we could add this at the end of each .desktop file: # # # automatically extracted OS version requirement information: # # REQUIRED_OS_MAJOR=1 # # REQUIRED_OS_MINOR=7 # # REQUIRED_OS_RELEASE=0 # # REQUIRED_OS_BUILD=0 # # In pnd_run.sh we could simply grep using these terms: # # grep "REQUIRED_OS_MAJOR" application.desktop | cut -d "=" -f2 # grep "REQUIRED_OS_MINOR" application.desktop | cut -d "=" -f2 # grep "REQUIRED_OS_RELEASE" application.desktop | cut -d "=" -f2 # grep "REQUIRED_OS_BUILD" application.desktop | cut -d "=" -f2
pnd_run gets run by .desktop, it doesnm't (currently) look back where it came from. It shouldn't really care about how it was invoked (via .desktop or directly, since it is not always run from a .desktop)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 24.02.2012 03:29, schrieb skeezix:
You misinterpret --
pndnotifyd rescans, and fills the Exec= line in the .desktop with a pnd_run_warning.sh instead of pnd_run.sh
Then when the user runs one of the 'old' apps, the warning comes up, and pnd_runm_warning.sh then runs pnd_run.sh with the same args, and everything goes.
ie: Easy change, no speed hit, just works ;)
Yeah, this sounds promising. So basically a wrapper script started before pnd_run.sh itself is called. Sounds like an elegant and sane solution to me.
pnd_run gets run by .desktop, it doesnm't (currently) look back where it came from. It shouldn't really care about how it was invoked (via .desktop or directly, since it is not always run from a .desktop)
Okay, then pnd_run does not know about the PXML (at all), right? Just to be sure about how things work together.
Cheers, Nils Kneuper aka Ivanovic
On Fri, Feb 24, 2012 at 12:41 PM, Nils Kneuper crazy-ivanovic@gmx.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 24.02.2012 03:29, schrieb skeezix:
You misinterpret --
pndnotifyd rescans, and fills the Exec= line in the .desktop with a pnd_run_warning.sh instead of pnd_run.sh
Then when the user runs one of the 'old' apps, the warning comes up, and pnd_runm_warning.sh then runs pnd_run.sh with the same args, and everything goes.
ie: Easy change, no speed hit, just works ;)
Yeah, this sounds promising. So basically a wrapper script started before pnd_run.sh itself is called. Sounds like an elegant and sane solution to me.
That could become an annoyance over time though, if an app thinks it needs newer firmware but still works good enough for the user on the the old one.
On Fri, 24 Feb 2012, Grazvydas Ignotas wrote:
# That could become an annoyance over time though, if an app thinks it # needs newer firmware but still works good enough for the user on the # the old one.
Checkbox in zenity maybe
[] Do not warn me again for this app
Stores a flag-file in appdata for the app, perhaps.
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
On Fri, 24 Feb 2012, Nils Kneuper wrote:
# > pnd_run gets run by .desktop, it doesnm't (currently) look back where it # > came from. It shouldn't really care about how it was invoked (via .desktop # > or directly, since it is not always run from a .desktop) # # Okay, then pnd_run does not know about the PXML (at all), right? Just to be # sure about how things work together.
Exactly so; pnd_run.sh takes everything from args, while the others (pndnotifyd, minimenu, pnd_run binary, etc) use libpnd which does the PXML parsing and emitting or invocation.
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 23.02.2012 22:54, schrieb Sébastien Huss:
2012/2/23 Nils Kneuper <crazy-ivanovic@gmx.net mailto:crazy-ivanovic@gmx.net>
strings youtube-dl.pnd | grep osversion | sed -e 's/.*major="(.*)" minor="(.*)" release="(.*)" build="(.*)".*/\1.\2.\3.\4/'
This wont work depending on the syntax used by the dev : <osversion major=1 minor=0 release=7 /> is valid as far as XML is concern, but wont be parsed by this command. You need to actually change libPND so it will provide that information to pnd_run.sh.
And then, what should pnd_run.sh do with that ?
Hmm, that is a good one, so the version has to be extracted somehow during the libpnd run and needs to be stored somehow so that it is easily available by pnd_run.sh... Or is there possibly some very lightweight xml parser we could use to extract the osversion during the run of pnd_run.sh? Currently you just rely on the (FDO compatible) .desktop files generated by libpnd, right? We could add some comment in those files which states the version, though would have to be done as part of libpnd. I think comments are possible in .desktop files, so this might be a way to go...
Btw in your sample you forgot the line for "build", all 4 params are mandatory... ;)
Cheers, Nils Kneuper aka Ivanovic
2012/2/23 Nils Kneuper crazy-ivanovic@gmx.net
Btw in your sample you forgot the line for "build", all 4 params are mandatory... ;)
While for .next pnd_run.sh will need to know the OS version. Your need dont. The script you attached in your first mail is what is requiered. It's the app (or it's wrapper) that need to know the it's HF7. pnd_run.sh cannot help knowing this (while for .next it will need to know if it will need to provide 1.0.0 compliant libraries).
Just include the notaz SDL version in your PND with your script and just dont add your bundled libSDL to LD_LIBRARY_PATH if the current PND run on HF7 or later ;)
cheers, sebt3
On Thu, 23 Feb 2012, Nils Kneuper wrote:
# Hmm, that is a good one, so the version has to be extracted somehow during the # libpnd run and needs to be stored somehow so that it is easily available by # pnd_run.sh... Or is there possibly some very lightweight xml parser we could # use to extract the osversion during the run of pnd_run.sh? Currently you just # rely on the (FDO compatible) .desktop files generated by libpnd, right? We # could add some comment in those files which states the version, though would # have to be done as part of libpnd. I think comments are possible in .desktop # files, so this might be a way to go...
Oh, aside from my other post you've not seen yet --
I've no problem adding to libpnd to include extra attributes in the .desktop; since recent hotfixes I've added quite a few to make minimenu's life easier, as its now using .desktop rather than a full pnd discovery itself (to leverage the work already done by pndnotifyd, since in 99.999% of installs mmenu is running alongside pndnotifyd, though of course the behaviour is configurable.)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.