Hi,
this has been brought before, but maybe did not get much attention. How about having optional <requirements> element in PXML, to list (in free form) whatever the given program needs to work? For example, quake would have: <requirements> <requirements lang="en_US">Copy the *.pak files from your game CD to pandora/appdata/quake/whatever</requirements> </requirements> gpSP: <requirements> <requirements lang="en_US">gpSP requires BIOS file that should be named gba_bios.bin and placed into /pandora/appdata/gpsp/ directory.</requirements> </requirements>
This could be shown by repo, packet managers, launchers. Right now this is expected to reside in readme, which is not shown by those for obvious reasons, so you have to download the pnd first and search over the readme for this info.
I think i brought up this problem when the pnd system was first being introduced, but it didnt really go anywhere. I also have to admit ive been a bit lazy on instructing the user on what files are need and where. Most of the time I wrote something up quick and sweet in a readme. As a result I have seen threads/comments by confused users on what to do.
Originally I wanted a mechanism in the pxml that could contain a list of files, which the system would look for and report back to the user. (I think i still like this method) Ive used some pnd's do their own checks (assume through scripts and zenity) and do not run until all required files are present. Maybe something as simple as a identifier that a pnd requires data that is not included, and the user is directed where to find the details on the data.
________________________________ From: Grazvydas Ignotas notasas@gmail.com To: firmware-dev@openpandora.org Sent: Tue, September 20, 2011 2:33:27 PM Subject: [Firmware-dev] requirements element i PXML?
Hi,
this has been brought before, but maybe did not get much attention. How about having optional <requirements> element in PXML, to list (in free form) whatever the given program needs to work? For example, quake would have: <requirements> <requirements lang="en_US">Copy the *.pak files from your game CD to pandora/appdata/quake/whatever</requirements> </requirements> gpSP: <requirements> <requirements lang="en_US">gpSP requires BIOS file that should be named gba_bios.bin and placed into /pandora/appdata/gpsp/ directory.</requirements> </requirements>
This could be shown by repo, packet managers, launchers. Right now this is expected to reside in readme, which is not shown by those for obvious reasons, so you have to download the pnd first and search over the readme for this info.
On Tue, 20 Sep 2011, Scott Smith wrote:
# I think i brought up this problem when the pnd system was first being # introduced, but it didnt really go anywhere. I also have to admit ive # been a bit lazy on instructing the user on what files are need and # where. Most of the time I wrote something up quick and sweet in a # readme. As a result I have seen threads/comments by confused users on # what to do. # # Originally I wanted a mechanism in the pxml that could contain a list of # files, which the system would look for and report back to the user. (I # think i still like this method) Ive used some pnd's do their own checks # (assume through scripts and zenity) and do not run until all required # files are present. Maybe something as simple as a identifier that a pnd # requires data that is not included, and the user is directed where to # find the details on the data.
Thought I originally had was a standard way to present info to the user (which turned into zenity, which is ugly but functional) and then folks run-scripts _should_ do the reporting; ie: since each app is so very different, and without wanting to create a whole language to describe requirements, I figured that was the way to go..
.. but alas, so few apps actually do that (or do it well), and of course the problem where the user may want to know _in advance_ (ie: not on pandora, but from the repo or whatever.)
The next idea that came along was 'long description' and 'short description' or perhaps 'short', 'long', 'install' -- multiple levels of description in the PXML (by language like everything else), with repos and package managers chosing which set to show.
We did add a 'requirements' crappy thing, where the PXML can say 'I need X11' and that sort, but never went very far there either.
--
I'm a fan of having the multiple descripotion levels, myself--
i) existing description which is 'free form'; can be short or long, so assume this is the 'full description' for compatibility [ ii) A 'short desc' which is 'required' (in the spec at least, perhaps enforced by libpnd) to be 'one sentence' or something; something required ot be short and presentable in a list on small screen/website. iii) install information
Note that we have..
<descriptions> <description...> </descriptions>
We could add in other types, right there:
<descriptions> <description...> <installhelp ...> <short ...> </descriptions>
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Hi there,
If we only want to inform the users before hand, then why indroducing yet others fields (that dev have to take care of, front-ends too ; what about these ~400 already exisint PNDs) when the current one could be used. The package description could already include that. I think the issue is more that, like pickle said, most dev are lazy on the instructions side (at least I do too).
If we want it on the pandora side, then I'll agree with Jeff : it should be part of the run script in the PND as we dont want to create a new language for describing all these dependencies.
Maybe, we need to communicate more to the devs on "how to package your apps/games in a PND cleanly"
Cheers, sebt3 2011/9/20 skeezix skeezix@skeleton.org
On Tue, 20 Sep 2011, Scott Smith wrote:
# I think i brought up this problem when the pnd system was first being # introduced, but it didnt really go anywhere. I also have to admit ive # been a bit lazy on instructing the user on what files are need and # where. Most of the time I wrote something up quick and sweet in a # readme. As a result I have seen threads/comments by confused users on # what to do. # # Originally I wanted a mechanism in the pxml that could contain a list of # files, which the system would look for and report back to the user. (I # think i still like this method) Ive used some pnd's do their own checks # (assume through scripts and zenity) and do not run until all required # files are present. Maybe something as simple as a identifier that a pnd # requires data that is not included, and the user is directed where to # find the details on the data.
Thought I originally had was a standard way to present info to the
user (which turned into zenity, which is ugly but functional) and then folks run-scripts _should_ do the reporting; ie: since each app is so very different, and without wanting to create a whole language to describe requirements, I figured that was the way to go..
.. but alas, so few apps actually do that (or do it well), and of
course the problem where the user may want to know _in advance_ (ie: not on pandora, but from the repo or whatever.)
The next idea that came along was 'long description' and 'short
description' or perhaps 'short', 'long', 'install' -- multiple levels of description in the PXML (by language like everything else), with repos and package managers chosing which set to show.
We did add a 'requirements' crappy thing, where the PXML can say
'I need X11' and that sort, but never went very far there either.
-- I'm a fan of having the multiple descripotion levels, myself-- i) existing description which is 'free form'; can be short or
long, so assume this is the 'full description' for compatibility [ ii) A 'short desc' which is 'required' (in the spec at least, perhaps enforced by libpnd) to be 'one sentence' or something; something required ot be short and presentable in a list on small screen/website. iii) install information
Note that we have.. <descriptions> <description...> </descriptions> We could add in other types, right there: <descriptions> <description...> <installhelp ...> <short ...> </descriptions> jeff
If we do this, I would propose to get rid of XML all together. XML is ugly and annoying to edit and is not needed for PND at all to be honest.
We could just live with bunch of variables that would be easy to parse and easy to edit such as:
pkgid=mega_pnd # for package managers
id=app1 categories=('Game', 'Office') licenses=('GPL') script=scripts/run.sh
id=app2 ... script=scripts/run2.sh
Also this would get rid of crappy tinyxml on PND-libraries that also forces to link against libstd++ where the libraries are all in C code.
Cheers.
2011/9/21 Sébastien Huss sebastien.huss@gmail.com:
Hi there, If we only want to inform the users before hand, then why indroducing yet others fields (that dev have to take care of, front-ends too ; what about these ~400 already exisint PNDs) when the current one could be used. The package description could already include that. I think the issue is more that, like pickle said, most dev are lazy on the instructions side (at least I do too). If we want it on the pandora side, then I'll agree with Jeff : it should be part of the run script in the PND as we dont want to create a new language for describing all these dependencies. Maybe, we need to communicate more to the devs on "how to package your apps/games in a PND cleanly" Cheers, sebt3 2011/9/20 skeezix skeezix@skeleton.org
On Tue, 20 Sep 2011, Scott Smith wrote:
# I think i brought up this problem when the pnd system was first being # introduced, but it didnt really go anywhere. I also have to admit ive # been a bit lazy on instructing the user on what files are need and # where. Most of the time I wrote something up quick and sweet in a # readme. As a result I have seen threads/comments by confused users on # what to do. # # Originally I wanted a mechanism in the pxml that could contain a list of # files, which the system would look for and report back to the user. (I # think i still like this method) Ive used some pnd's do their own checks # (assume through scripts and zenity) and do not run until all required # files are present. Maybe something as simple as a identifier that a pnd # requires data that is not included, and the user is directed where to # find the details on the data.
Thought I originally had was a standard way to present info to the user (which turned into zenity, which is ugly but functional) and then folks run-scripts _should_ do the reporting; ie: since each app is so very different, and without wanting to create a whole language to describe requirements, I figured that was the way to go..
.. but alas, so few apps actually do that (or do it well), and of course the problem where the user may want to know _in advance_ (ie: not on pandora, but from the repo or whatever.)
The next idea that came along was 'long description' and 'short description' or perhaps 'short', 'long', 'install' -- multiple levels of description in the PXML (by language like everything else), with repos and package managers chosing which set to show.
We did add a 'requirements' crappy thing, where the PXML can say 'I need X11' and that sort, but never went very far there either.
--
I'm a fan of having the multiple descripotion levels, myself--
i) existing description which is 'free form'; can be short or long, so assume this is the 'full description' for compatibility [ ii) A 'short desc' which is 'required' (in the spec at least, perhaps enforced by libpnd) to be 'one sentence' or something; something required ot be short and presentable in a list on small screen/website. iii) install information
Note that we have..
<descriptions> <description...> </descriptions>
We could add in other types, right there:
<descriptions> <description...> <installhelp ...> <short ...> </descriptions>
jeff
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
To be honest I think trying to include other package dependencies makes this complicated than it should be. And in most cases everything is on pandora to anyways. If im missing a library that is not in the firmware I include in the pnd. So i think for very many of existing pnds they just run.
I think this should be kept simple and just be used to verify data content.
________________________________ From: Sébastien Huss sebastien.huss@gmail.com To: firmware-dev@openpandora.org Sent: Tue, September 20, 2011 5:42:01 PM Subject: Re: [Firmware-dev] requirements element i PXML?
Hi there,
If we only want to inform the users before hand, then why indroducing yet others fields (that dev have to take care of, front-ends too ; what about these ~400 already exisint PNDs) when the current one could be used. The package description could already include that. I think the issue is more that, like pickle said, most dev are lazy on the instructions side (at least I do too).
If we want it on the pandora side, then I'll agree with Jeff : it should be part of the run script in the PND as we dont want to create a new language for describing all these dependencies.
Maybe, we need to communicate more to the devs on "how to package your apps/games in a PND cleanly"
Cheers, sebt3 2011/9/20 skeezix skeezix@skeleton.org
On Tue, 20 Sep 2011, Scott Smith wrote:
# I think i brought up this problem when the pnd system was first being
# introduced, but it didnt really go anywhere. I also have to admit ive # been a bit lazy on instructing the user on what files are need and # where. Most of the time I wrote something up quick and sweet in a # readme. As a result I have seen threads/comments by confused users on # what to do. # # Originally I wanted a mechanism in the pxml that could contain a list of # files, which the system would look for and report back to the user. (I # think i still like this method) Ive used some pnd's do their own checks # (assume through scripts and zenity) and do not run until all required # files are present. Maybe something as simple as a identifier that a pnd # requires data that is not included, and the user is directed where to # find the details on the data.
Thought I originally had was a standard way to present info to the
user (which turned into zenity, which is ugly but functional) and then folks run-scripts _should_ do the reporting; ie: since each app is so very different, and without wanting to create a whole language to describe requirements, I figured that was the way to go..
.. but alas, so few apps actually do that (or do it well), and of
course the problem where the user may want to know _in advance_ (ie: not on pandora, but from the repo or whatever.)
The next idea that came along was 'long description' and 'short
description' or perhaps 'short', 'long', 'install' -- multiple levels of description in the PXML (by language like everything else), with repos and package managers chosing which set to show.
We did add a 'requirements' crappy thing, where the PXML can say
'I need X11' and that sort, but never went very far there either.
-- I'm a fan of having the multiple descripotion levels, myself-- i) existing description which is 'free form'; can be short or
long, so assume this is the 'full description' for compatibility [ ii) A 'short desc' which is 'required' (in the spec at least, perhaps enforced by libpnd) to be 'one sentence' or something; something required ot be short and presentable in a list on small screen/website. iii) install information
Note that we have.. <descriptions> <description...> </descriptions> We could add in other types, right there: <descriptions> <description...> <installhelp ...> <short ...> </descriptions> jeff
On Wed, 21 Sep 2011, Jari Vetoniemi wrote:
# If we do this, I would propose to get rid of XML all together. # XML is ugly and annoying to edit and is not needed for PND at all to be honest.
Probably not a great time to change the spec (but also doable, given it almost all funnels through libpnd so supporting two specs can be done, just ugly :)
If we did this, we'd just go back to straight .desktop file approach (which maybe we should've done day zero)
Aside .. I think XML grew big, then melted; no one wants it, we all just use JSON or back to basics again :) (and heck, libpnd already has a basic conf file reader/writer as well, for INI-style files)
No, our problem is drive-by devs who throw pnds out without documentation or useful runscript and bad categories :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
On Wed, Sep 21, 2011 at 12:42 AM, Sébastien Huss sebastien.huss@gmail.com wrote:
Hi there, If we only want to inform the users before hand, then why indroducing yet others fields (that dev have to take care of, front-ends too ; what about these ~400 already exisint PNDs) when the current one could be used. The package description could already include that. I think the issue is more that, like pickle said, most dev are lazy on the instructions side (at least I do too).
Well the idea is if there was a field to enter requirements, maybe it would encourage people to actually use it. Right now when you make a pnd you do: - see author element - fill it in - see titles element - fill it in - see descriptions - fill it in ... done.
the system doesn't even offer you to specify requirements, and you don't do it. If there was such a field, chances are you would fill it in. Descriptions don't really ask a question "what does your app require?".
And I'm not talking about super magic dependency resolver or library checker - just a free text form field for emulators, quake-like games that need data files and the likes. This is just to save the user from having to parse the readme for this info.
Expanding <descriptions> for this would be fine for me.
Maybe, we need to communicate more to the devs on "how to package your apps/games in a PND cleanly"
Maybe someone could code a web-based PXML generator? Basically you fill a form of several fields and it spits out valid PXML? I think it would be quick and useful project someone like Milkshake could take.
On Wed, 21 Sep 2011, Grazvydas Ignotas wrote:
# checker - just a free text form field for emulators, quake-like games # that need data files and the likes. This is just to save the user from # having to parse the readme for this info.
It annys me that so many people just added an 'info line', and called it 'readme', not realzing that having 10 entries in the menu saying 'readme' doesn't help anyone.
We really need peopel to actually try their pnds before uploading to repos, but they don't ;)
# Maybe someone could code a web-based PXML generator? Basically you # fill a form of several fields and it spits out valid PXML? I think it # would be quick and useful project someone like Milkshake could take.
Good idea!
-- If everyone would put barbecue sauce on their food, there would be no war.