Hello admins/devs of the BugTracker!
ED had given me admin permissions for the BugTracker, in order to check its settings, and I think, as they are now, most of the troubles reported in FS#245 are fixed.
Nevertheless, I ask you to please go through this my evaluation, to answer remaining questions concerning the BugTracker.
And, if I am certain, that I am fully aware of the BugTracker, I offer to you to update its documentation/help at http://pandorawiki.org/Reporting_bugs accordingly.
Regards, Stefan Nowak from Vienna (porg)
---
!! Global versus project-based user groups
This is the status quo at http://bugs.openpandora.org : * User groups are configured for "All projects" (=globally). * The particular projects seem to have no user groups set up, and simply use the global user groups.
I think this is a good principle, as OpenPandora is an open source approach. Distinct user groups per project seem to only make sense for security/secret projects. The only other reason, I could think of, is as a workaround to achieve fine-grained notifications. But the setup as of now seems pretty reasonable as it is.
!! User groups & registration
Active user groups: * Admin: Can do everything. * Developer: Can do almost anything. (Only non-granted permissions: Project Manager, View event log) * Basic: As the name already tells. I looked at this group's permissions, and it seems that my inquiry FS#245 is almost solved by how this group's settings are.
Default global group for new users: Basic.
These user groups have no members, seem to be un-used: * Pending * Reporters
What was/is their purpose? Any intentions to use them still/again?
I guess the thought behind this was: * Give freshly registered users enough trust (can create and delete their own content, but not edit/delete others' content), so the worst which could happen is if they report redundantly, write inpolitely, or spam. * For the case that this setup does not work so fine, you will change auto-assignment of new users to "Pending" (which has no rights at all, even less than the anonymous user who can at least view), and approve new users manually.
Right?
!! Permissions
!!! Permissions granted to Basic
Members can login View history View tasks
Open new tasks Modify own tasks # Part of fixing FS#245. Close own tasks # Part of fixing FS#245.
View comments Add comments Edit own comments # Part of fixing FS#245. Create attachments
Assign tasks to self if not already assigned Assign others' tasks to self Add self to assignees
!!! Permissions only granted to Developer and Admin
Modify tasks that are not user's own Close tasks that are not user's own Edit comments Delete comments Delete attachments
Edit assignments Show as assignees Can Vote for tasks
!! Basic user - Open questions concerning FS#245
!!!! Delete own attachments
I think basic users should have the ability to "Delete own attachments". I do not see this particular permission within FlySpray. I only see the permission "Delete attachments", but we can't grant this to basic users. So as it seems, attachments once uploaded cannot be removed anymore. Right? If it is like this, I would like to add this info to http://pandorawiki.org/Reporting_bugs
!!!! Assignment
Basic currently has these permissions: * Assign tasks to self if not already assigned * Assign others' tasks to self * Add self to assignees
Basic currently lacks these permissions: * Edit assignments * Show as assignees
These are my arising questions:
* My observation: The basic user can either assign a task to an Admin, a Developer or to him/her-self, but not to other Basic users. One of the developers is called "openpandora", who I guess shall be assigned if the Basic user is uncertain, or if the Developers decide to assign a shared responsibility. Are my assumptions correct? If so, I would like this to also be documented at: http://pandorawiki.org/Reporting_bugs
* If the basic user assigns a task to him/her-self, can he/she later un-assign her/him-self?
* What does "Show as assignees" mean? That the user shows as a possible choice for "Assigned To" within the task submission form? Or that a user is shown as assignee in task listings or detailed task views? The English noun "assignee" is ambiguous, thus a short remark in German between porg and EvilDragon which may helps to get to a clear understanding: Wir haben in Deutsch die Möglichkeit zu sagen "Zugeteilter" (=hat die Verantwortung übernommen, "assigned person") oder "Zuteilbarer" (=steht zur Verfügung um die Verantwortung zu übernehmen "assignable person").
On Sun, 29 Jan 2012, Stefan Nowak wrote:
# Hello admins/devs of the BugTracker! # ED had given me admin permissions for the BugTracker, in order to check its settings, and I think, as they are now, most of the troubles reported in FS#245 are fixed.
hey, fun :)
Just doing a quick drop by and run (I donm't have much time on weekends), but recently I had an issue where the tracker didn't really work too well -- the comment field area was broken; hopefully thats all sorted out now just by having you beating around on it :) Will check it out soon.
Thanks for picking up one of the pieces .. we need more people like you helping out :)
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Hi!
On 30.01.2012 at 03:19 Skeezix wrote:
On Sun, 29 Jan 2012, Stefan Nowak (porg) wrote:
Thanks for picking up one of the pieces .. we need more people like you helping out :)
You're welcome.
ED had given me admin permissions for the BugTracker, in order to check its settings, and I think, as they are now, most of the troubles reported in FS#245 are fixed.
Recently I had an issue where the tracker didn't really work too well -- the comment field area was broken
Adding comments worked for porg (admin), testporgdev (dev), testporg (basic).
Sadly, from the recent testing I can now confirm that "Delete own comments" (and "Delete own attachments" as already reported) are non-available options within FireFly. Only the overall "Delete comments" and "Delete attachments" is available, and this is only granted to Admin and Developer, for good reasons.
hopefully thats all sorted out now just by having you beating around on it :) Will check it out soon.
Not everything is yet sorted out. I had just accurately reported all drawbacks, but yet someone has to fix them. Obviously first adding the missing files to the installation, and then go through my detailed list and check them one by one:
1) Some bullet points may dissolve as the bug tracker gets complete (in files and thus functions), 2) some may remain as some settings may still be wrong, 3) some may be unresolvable as FireFly lacks the needed functionality.
Regards, Stefan (porg)
One more issue:
Editing a comment of an issue DOES NOT notify any of the related/assigned persons. This setting is not fine, but FireFly seems to have no setting, and likely no respective functionality, for this.
Does anyone know whether this is an installation defect of FireFly or intentionally designed that way? If it is by design, then at least this circumstance must be added to the guideline at: http://pandorawiki.org/Reporting_bugs
Otherwise some people may correct some parts of an original comment, and then wonder why no-one re-acts. If they are aware of how this notification system works, they will instead add a new post (and possibly still edit the old one, to prevent the presence of dangerous false information, or leave the old one for chronological/transparency purposes, and possibly still add a short remark to ignore the old (possibly dangerous) facts and look for later comments).
Regards, Stefan (porg)
On Mon, 30 Jan 2012, Stefan Nowak wrote:
# >> ED had given me admin permissions for the BugTracker, in order to check its settings, and I think, as they are now, most of the troubles reported in FS#245 are fixed. # > # > Recently I had an issue where the tracker didn't really work too well -- the comment field area was broken # # Adding comments worked for porg (admin), testporgdev (dev), testporg (basic). # # Sadly, from the recent testing I can now confirm that "Delete own comments" (and "Delete own attachments" as already reported) are non-available options within FireFly. Only the overall "Delete comments" and "Delete attachments" is available, and this is only granted to Admin and Developer, for good reasons.
Looks sorted out now; a temporary issue then, so disregard.
Only remaining oddity is when pulling up a page, theres a "Loading..." bit at the bottom that doesn't seem to resolve, but doesn't seem to be a problem.
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
On 21.02.2012 at 22:19 Grazvydas Ignotas wrote in another email:
Somebody should fix the bugtracker..
Totally agree with that! Therefore I took the effort and wrote a detailed review (see below), but so far, NOBODY, except Skeezix, took the courtesy/effort to even reply, not to mention, act on it!
Slightly dissapointed, but yet full of hope, yours sincerely: porg
On 29.01.2012 at 19:38 Stefan Nowak (porg) wrote:
Hello admins/devs of the BugTracker!
ED had given me admin permissions for the BugTracker, in order to check its settings, and I think, as they are now, most of the troubles reported in FS#245 are fixed.
Nevertheless, I ask you to please go through this my evaluation, to answer remaining questions concerning the BugTracker.
And, if I am certain, that I am fully aware of the BugTracker, I offer to you to update its documentation/help at http://pandorawiki.org/Reporting_bugs accordingly.
Regards, Stefan Nowak from Vienna (porg)
!! Global versus project-based user groups
This is the status quo at http://bugs.openpandora.org :
- User groups are configured for "All projects" (=globally).
- The particular projects seem to have no user groups set up, and simply use the global user groups.
I think this is a good principle, as OpenPandora is an open source approach. Distinct user groups per project seem to only make sense for security/secret projects. The only other reason, I could think of, is as a workaround to achieve fine-grained notifications. But the setup as of now seems pretty reasonable as it is.
!! User groups & registration
Active user groups:
- Admin: Can do everything.
- Developer: Can do almost anything. (Only non-granted permissions: Project Manager, View event log)
- Basic: As the name already tells. I looked at this group's permissions, and it seems that my inquiry FS#245 is almost solved by how this group's settings are.
Default global group for new users: Basic.
These user groups have no members, seem to be un-used:
- Pending
- Reporters
What was/is their purpose? Any intentions to use them still/again?
I guess the thought behind this was:
- Give freshly registered users enough trust (can create and delete their own content, but not edit/delete others' content), so the worst which could happen is if they report redundantly, write inpolitely, or spam.
- For the case that this setup does not work so fine, you will change auto-assignment of new users to "Pending" (which has no rights at all, even less than the anonymous user who can at least view), and approve new users manually.
Right?
!! Permissions
!!! Permissions granted to Basic
Members can login View history View tasks
Open new tasks Modify own tasks # Part of fixing FS#245. Close own tasks # Part of fixing FS#245.
View comments Add comments Edit own comments # Part of fixing FS#245. Create attachments
Assign tasks to self if not already assigned Assign others' tasks to self Add self to assignees
!!! Permissions only granted to Developer and Admin
Modify tasks that are not user's own Close tasks that are not user's own Edit comments Delete comments Delete attachments
Edit assignments Show as assignees Can Vote for tasks
!! Basic user - Open questions concerning FS#245
!!!! Delete own attachments
I think basic users should have the ability to "Delete own attachments". I do not see this particular permission within FlySpray. I only see the permission "Delete attachments", but we can't grant this to basic users. So as it seems, attachments once uploaded cannot be removed anymore. Right? If it is like this, I would like to add this info to http://pandorawiki.org/Reporting_bugs
!!!! Assignment
Basic currently has these permissions:
- Assign tasks to self if not already assigned
- Assign others' tasks to self
- Add self to assignees
Basic currently lacks these permissions:
- Edit assignments
- Show as assignees
These are my arising questions:
My observation: The basic user can either assign a task to an Admin, a Developer or to him/her-self, but not to other Basic users. One of the developers is called "openpandora", who I guess shall be assigned if the Basic user is uncertain, or if the Developers decide to assign a shared responsibility. Are my assumptions correct? If so, I would like this to also be documented at: http://pandorawiki.org/Reporting_bugs
If the basic user assigns a task to him/her-self, can he/she later un-assign her/him-self?
What does "Show as assignees" mean? That the user shows as a possible choice for "Assigned To" within the task submission form? Or that a user is shown as assignee in task listings or detailed task views? The English noun "assignee" is ambiguous, thus a short remark in German between porg and EvilDragon which may helps to get to a clear understanding: Wir haben in Deutsch die Möglichkeit zu sagen "Zugeteilter" (=hat die Verantwortung übernommen, "assigned person") oder "Zuteilbarer" (=steht zur Verfügung um die Verantwortung zu übernehmen "assignable person").
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
Hiya,
Just to chime in on this...
Somebody should fix the bugtracker..
Totally agree with that! Therefore I took the effort and wrote a detailed review (see below), but so far, NOBODY, except Skeezix, took the courtesy/effort to even reply, not to mention, act on it!
Slightly dissapointed, but yet full of hope, yours sincerely: porg
Only really just noticed your 1st post but for various personal reasons I am not doing a great deal if anything at the moment anyway.
ED had given me admin permissions for the BugTracker, in order to check
its settings, and I think, as they are now, most of the troubles reported
in
FS#245 are fixed.
Nevertheless, I ask you to please go through this my evaluation, to
answer
remaining questions concerning the BugTracker.
And, if I am certain, that I am fully aware of the BugTracker, I offer
to you to
update its documentation/help at http://pandorawiki.org/Reporting_bugs accordingly.
Great that someone is looking at it.
!! Global versus project-based user groups
This is the status quo at http://bugs.openpandora.org :
- User groups are configured for "All projects" (=globally).
- The particular projects seem to have no user groups set up, and simply
use the global user groups.
I think this is a good principle, as OpenPandora is an open source
approach.
Distinct user groups per project seem to only make sense for
security/secret
projects. The only other reason, I could think of, is as a workaround to achieve fine-grained notifications.
But the setup as of now seems pretty reasonable as it is.
Yep, global all the way.
!! User groups & registration
Active user groups:
- Admin: Can do everything.
- Developer: Can do almost anything. (Only non-granted permissions:
Project Manager, View event log)
- Basic: As the name already tells. I looked at this group's
permissions, and
it seems that my inquiry FS#245 is almost solved by how this group's
settings
are.
Default global group for new users: Basic.
These user groups have no members, seem to be un-used:
- Pending
- Reporters
What was/is their purpose? Any intentions to use them still/again?
I guess the thought behind this was:
- Give freshly registered users enough trust (can create and delete
their
own content, but not edit/delete others' content), so the worst which
could
happen is if they report redundantly, write inpolitely, or spam.
- For the case that this setup does not work so fine, you will change
auto-
assignment of new users to "Pending" (which has no rights at all, even
less
than the anonymous user who can at least view), and approve new users manually.
Right?
Don't over engineer it, they are default groups, I guess they can be deleted, you really only need users, team and admins (or Basic, Developer and Admin in our case).
!! Permissions
!!! Permissions granted to Basic
Members can login View history View tasks
Open new tasks Modify own tasks # Part of fixing FS#245. Close own tasks # Part of fixing FS#245.
View comments Add comments Edit own comments # Part of fixing FS#245. Create attachments
Assign tasks to self if not already assigned Assign others' tasks to self Add self to assignees
!!! Permissions only granted to Developer and Admin
Modify tasks that are not user's own Close tasks that are not user's own Edit comments Delete comments Delete attachments
Edit assignments Show as assignees Can Vote for tasks
!! Basic user - Open questions concerning FS#245
!!!! Delete own attachments
I think basic users should have the ability to "Delete own attachments".
I do
not see this particular permission within FlySpray. I only see the
permission
"Delete attachments", but we can't grant this to basic users.
So as it seems, attachments once uploaded cannot be removed anymore.
Right?
If it is like this, I would like to add this info to http://pandorawiki.org/Reporting_bugs
I am honestly not so sure that deleting attachments is all that common place, most trackers I use let you upload new 'versions' but not easily pull out an old one. I guess it's a transparency and audit thing.
!!!! Assignment
Basic currently has these permissions:
- Assign tasks to self if not already assigned
- Assign others' tasks to self
- Add self to assignees
Basic currently lacks these permissions:
- Edit assignments
- Show as assignees
These are my arising questions:
- My observation: The basic user can either assign a task to an Admin,
a Developer or to him/her-self, but not to other Basic users. One of the developers is called "openpandora", who I guess shall be assigned if the Basic user is uncertain, or if the Developers decide to assign a shared responsibility. Are my assumptions correct? If so, I would like this to also be documented at: http://pandorawiki.org/Reporting_bugs
- If the basic user assigns a task to him/her-self, can he/she later
un-assign
her/him-self?
I don't see why not, each project can have a default assignment and it's not uncommon to have a 'Pending' user that gets the default assignments on small projects pending review. We currently let a record without mandatory assignments, anything wrong with that? Comments?
- What does "Show as assignees" mean? That the user shows as a possible
choice for "Assigned To" within the task submission form? Or that a user
is
shown as assignee in task listings or detailed task views? The English
noun
"assignee" is ambiguous, thus a short remark in German between porg and EvilDragon which may helps to get to a clear understanding: Wir haben in Deutsch die Möglichkeit zu sagen "Zugeteilter" (=hat die Verantwortung übernommen, "assigned person") oder "Zuteilbarer" (=steht zur Verfügung um die Verantwortung zu übernehmen "assignable person").
" Show as assignees" is the permission that lets a user show up in the in the assignments list for calls (Assigned To). Your understanding is correct.
Regards,
John
Dear John: Thanks for answering quite many questions. Dear others: Please answer the remaining questions. I will then summarize these guidelines in the wiki.
Regards, porg
Am 22.02.2012 um 21:24 schrieb John Willis:
Hiya,
Just to chime in on this...
Somebody should fix the bugtracker..
Totally agree with that! Therefore I took the effort and wrote a detailed review (see below), but so far, NOBODY, except Skeezix, took the courtesy/effort to even reply, not to mention, act on it!
Slightly dissapointed, but yet full of hope, yours sincerely: porg
Only really just noticed your 1st post but for various personal reasons I am not doing a great deal if anything at the moment anyway.
ED had given me admin permissions for the BugTracker, in order to check
its settings, and I think, as they are now, most of the troubles reported
in
FS#245 are fixed.
Nevertheless, I ask you to please go through this my evaluation, to
answer
remaining questions concerning the BugTracker.
And, if I am certain, that I am fully aware of the BugTracker, I offer
to you to
update its documentation/help at http://pandorawiki.org/Reporting_bugs accordingly.
Great that someone is looking at it.
!! Global versus project-based user groups
This is the status quo at http://bugs.openpandora.org :
- User groups are configured for "All projects" (=globally).
- The particular projects seem to have no user groups set up, and simply
use the global user groups.
I think this is a good principle, as OpenPandora is an open source
approach.
Distinct user groups per project seem to only make sense for
security/secret
projects. The only other reason, I could think of, is as a workaround to achieve fine-grained notifications.
But the setup as of now seems pretty reasonable as it is.
Yep, global all the way.
!! User groups & registration
Active user groups:
- Admin: Can do everything.
- Developer: Can do almost anything. (Only non-granted permissions:
Project Manager, View event log)
- Basic: As the name already tells. I looked at this group's
permissions, and
it seems that my inquiry FS#245 is almost solved by how this group's
settings
are.
Default global group for new users: Basic.
These user groups have no members, seem to be un-used:
- Pending
- Reporters
What was/is their purpose? Any intentions to use them still/again?
I guess the thought behind this was:
- Give freshly registered users enough trust (can create and delete
their
own content, but not edit/delete others' content), so the worst which
could
happen is if they report redundantly, write inpolitely, or spam.
- For the case that this setup does not work so fine, you will change
auto-
assignment of new users to "Pending" (which has no rights at all, even
less
than the anonymous user who can at least view), and approve new users manually.
Right?
Don't over engineer it, they are default groups, I guess they can be deleted, you really only need users, team and admins (or Basic, Developer and Admin in our case).
!! Permissions
!!! Permissions granted to Basic
Members can login View history View tasks
Open new tasks Modify own tasks # Part of fixing FS#245. Close own tasks # Part of fixing FS#245.
View comments Add comments Edit own comments # Part of fixing FS#245. Create attachments
Assign tasks to self if not already assigned Assign others' tasks to self Add self to assignees
!!! Permissions only granted to Developer and Admin
Modify tasks that are not user's own Close tasks that are not user's own Edit comments Delete comments Delete attachments
Edit assignments Show as assignees Can Vote for tasks
!! Basic user - Open questions concerning FS#245
!!!! Delete own attachments
I think basic users should have the ability to "Delete own attachments".
I do
not see this particular permission within FlySpray. I only see the
permission
"Delete attachments", but we can't grant this to basic users.
So as it seems, attachments once uploaded cannot be removed anymore.
Right?
If it is like this, I would like to add this info to http://pandorawiki.org/Reporting_bugs
I am honestly not so sure that deleting attachments is all that common place, most trackers I use let you upload new 'versions' but not easily pull out an old one. I guess it's a transparency and audit thing.
!!!! Assignment
Basic currently has these permissions:
- Assign tasks to self if not already assigned
- Assign others' tasks to self
- Add self to assignees
Basic currently lacks these permissions:
- Edit assignments
- Show as assignees
These are my arising questions:
- My observation: The basic user can either assign a task to an Admin,
a Developer or to him/her-self, but not to other Basic users. One of the developers is called "openpandora", who I guess shall be assigned if the Basic user is uncertain, or if the Developers decide to assign a shared responsibility. Are my assumptions correct? If so, I would like this to also be documented at: http://pandorawiki.org/Reporting_bugs
- If the basic user assigns a task to him/her-self, can he/she later
un-assign
her/him-self?
I don't see why not, each project can have a default assignment and it's not uncommon to have a 'Pending' user that gets the default assignments on small projects pending review. We currently let a record without mandatory assignments, anything wrong with that? Comments?
- What does "Show as assignees" mean? That the user shows as a possible
choice for "Assigned To" within the task submission form? Or that a user
is
shown as assignee in task listings or detailed task views? The English
noun
"assignee" is ambiguous, thus a short remark in German between porg and EvilDragon which may helps to get to a clear understanding: Wir haben in Deutsch die Möglichkeit zu sagen "Zugeteilter" (=hat die Verantwortung übernommen, "assigned person") oder "Zuteilbarer" (=steht zur Verfügung um die Verantwortung zu übernehmen "assignable person").
" Show as assignees" is the permission that lets a user show up in the in the assignments list for calls (Assigned To). Your understanding is correct.
Regards,
John
Some folks have brought up a request to possibly augment the PXML specification slightly. A little too much drama but hey, its the Internet :)
In discussion is .. preview pics and the concept of 'primary preview pic'; ie: If an applicatio nis to show only a single primary pic out of a number oif supplied ones, how does it know which one to present?
Traditionally (by which I mean minimenu and maybe a few other apps) the first preview pic has been shown. The 'repo' shows them all (in reverse order, perhaps until recently?).
XML data is I think assumed to be unordered (while HTML and SGML are ordered), as technically there shoudl be an ordering attribute.
Some options that fall out..
i) Add a note to the PXML spec to hard define that order is important, in that 'first preview pic mentioned' is 'preferred pic, if you only want one'; that lacks ordering after first, but at least defines first, and requires minimal changes to existing code.
ii) Add some ordering attributes to the elements; be it just 'primary' flag, or perhaps 'order=1' 'order=2' etc, some way to identify sequence. Or evej somethign goofy like "type='titlescreen' order='1'" .. but that seems extreme to me, when many don't care at all. Donmt' need to overdo it..
iii) Do nothing; leave it as a 'soup' of images, and no defined ordering.
Examples in other 'app store' type environments.. I don't recall offhand. I'm at work and sleepy right now :)
Implications: Changes may require code changes in libpjnd, minimenu, repo, milky, pndstore, pnd updatey thign from the compo, etc. So minimal or no changes are best, perhaps..
I'm okay with doing nothing, or the order of implying ordering by order in PXML seems goofy yet reasonable; we could also add a 1/2/3/4/54 type ordering number, but that implies code changes. I'm not really interested in going further than 1/2/3/4 type simple numbering.
Does anyone have an opinion here?
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
2012/4/30 skeezix skeezix@skeleton.org
Does anyone have an opinion here?
yep ;)
As you said, there is no ordering in the preview pics, but for me it's not mandatory. The main issue is that the rss stream from the repo pick one randomly. 2 options : 1) get the repo show all the preview pics in the rss stream (and maybe get minimenu cycle the previews) 2) forget about this as if you want to see more you click on the link in your rss reader and see all the pics
cheers
Hi,
First mail here, yeeehah :D
I agree with Sébastien that is a client issue more than a spec one. Not all PNDs have preview pics anyway... So getting people to add preview pics AND order/tag them correctly would be complicated, IMHO.
Clop'
On Mon, 30 Apr 2012 11:08:52 -0400 Sébastien Huss sebastien.huss@gmail.com wrote:
2012/4/30 skeezix skeezix@skeleton.org
Does anyone have an opinion here?
yep ;)
As you said, there is no ordering in the preview pics, but for me it's not mandatory. The main issue is that the rss stream from the repo pick one randomly. 2 options :
- get the repo show all the preview pics in the rss stream (and maybe get
minimenu cycle the previews) 2) forget about this as if you want to see more you click on the link in your rss reader and see all the pics
cheers
Personally, I disable previews on my Pandora, slows it down, and I know what my games/apps are :)
And if I'm browsing the repo, or the PND Management app, I'll tend to flick through all the pictures anyway.
So personally, the "do nothing" approach works for me :)
Alternatively, you could add the "order" attribute to the spec, but make it completely optional, then it's up to anybody parsing the files if they want to do anything with it.
Monday, April 30, 2012, 3:37:08 PM, you wrote:
s> Some folks have brought up a request to possibly augment the PXML s> specification slightly. A little too much drama but hey, its the Internet s> :)
s> In discussion is .. preview pics and the concept of 'primary s> preview pic'; ie: If an applicatio nis to show only a single primary pic s> out of a number oif supplied ones, how does it know which one to present?
s> Traditionally (by which I mean minimenu and maybe a few other s> apps) the first preview pic has been shown. The 'repo' shows them all (in s> reverse order, perhaps until recently?).
s> XML data is I think assumed to be unordered (while HTML and SGML s> are ordered), as technically there shoudl be an ordering attribute.
s> Some options that fall out..
s> i) Add a note to the PXML spec to hard define that order is s> important, in that 'first preview pic mentioned' is 'preferred pic, if you s> only want one'; that lacks ordering after first, but at least defines s> first, and requires minimal changes to existing code.
s> ii) Add some ordering attributes to the elements; be it just s> 'primary' flag, or perhaps 'order=1' 'order=2' etc, some way to identify s> sequence. Or evej somethign goofy like "type='titlescreen' order='1'" .. s> but that seems extreme to me, when many don't care at all. Donmt' need to s> overdo it..
s> iii) Do nothing; leave it as a 'soup' of images, and no defined s> ordering.
s> Examples in other 'app store' type environments.. I don't recall s> offhand. I'm at work and sleepy right now :)
s> Implications: Changes may require code changes in libpjnd, s> minimenu, repo, milky, pndstore, pnd updatey thign from the compo, etc. So s> minimal or no changes are best, perhaps..
s> I'm okay with doing nothing, or the order of implying ordering by s> order in PXML seems goofy yet reasonable; we could also add a 1/2/3/4/54 s> type ordering number, but that implies code changes. I'm not really s> interested in going further than 1/2/3/4 type simple numbering.
s> Does anyone have an opinion here?
s> jeff
s> -- s> If everyone would put barbecue sauce on their food, there would be no war. s> _______________________________________________ s> Firmware-dev mailing list s> Firmware-dev@openpandora.org s> http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev