Don't forget we also have the additional info option in the repo that can be used for things that could be needed to know beforehand.

Jake (milkshake)

Sent from my Windows Phone

From: firmware-dev-request@openpandora.org
Sent: 21/09/2011 11:00
To: firmware-dev@openpandora.org
Subject: Firmware-dev Digest, Vol 8, Issue 5

Send Firmware-dev mailing list submissions to
        firmware-dev@openpandora.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
or, via email, send a message with subject or body 'help' to
        firmware-dev-request@openpandora.org

You can reach the person managing the list at
        firmware-dev-owner@openpandora.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Firmware-dev digest..."


Today's Topics:

   1. requirements element i PXML? (Grazvydas Ignotas)
   2. Re: requirements element i PXML? (Scott Smith)
   3. Re: requirements element i PXML? (skeezix)
   4. Re: requirements element i PXML? (S?bastien Huss)


----------------------------------------------------------------------

Message: 1
Date: Tue, 20 Sep 2011 21:33:27 +0300
From: Grazvydas Ignotas <notasas@gmail.com>
To: firmware-dev@openpandora.org
Subject: [Firmware-dev] requirements element i PXML?
Message-ID:
        <CANOLnOM+QVEn=BY+eGHiVpkvf-C+GWxaAMNFz0hhdynF2CvHYw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

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.

--
Gra?vydas


------------------------------

Message: 2
Date: Tue, 20 Sep 2011 13:35:01 -0700 (PDT)
From: Scott Smith <pickle136@sbcglobal.net>
To: Grazvydas Ignotas <notasas@gmail.com>,
        firmware-dev@openpandora.org
Subject: Re: [Firmware-dev] requirements element i PXML?
Message-ID:
        <1316550901.32996.YahooMailRC@web180002.mail.gq1.yahoo.com>
Content-Type: text/plain; charset="utf-8"

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.

--
Gra?vydas
_______________________________________________
Firmware-dev mailing list
Firmware-dev@openpandora.org
http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openpandora.org/pipermail/firmware-dev/attachments/20110920/07d90b68/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 20 Sep 2011 16:56:50 -0400 (EDT)
From: skeezix <skeezix@skeleton.org>
To: Scott Smith <pickle136@sbcglobal.net>
Cc: firmware-dev@openpandora.org
Subject: Re: [Firmware-dev] requirements element i PXML?
Message-ID: <alpine.DEB.2.00.1109201652000.2775@kronos.skeleton.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII

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.


------------------------------

Message: 4
Date: Tue, 20 Sep 2011 17:42:01 -0400
From: S?bastien Huss <sebastien.huss@gmail.com>
To: firmware-dev@openpandora.org
Subject: Re: [Firmware-dev] requirements element i PXML?
Message-ID:
        <CADFh8+X=d8Zu4rX5_KURP6mO3bzaqqQuthwbe8JMY+kMaT4Ugw@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openpandora.org/pipermail/firmware-dev/attachments/20110920/6ff7165a/attachment-0001.html>

------------------------------

_______________________________________________
Firmware-dev mailing list
Firmware-dev@openpandora.org
http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev


End of Firmware-dev Digest, Vol 8, Issue 5
******************************************