Pandora PND packagers: 1) Please provide previewpics. 2) Define primary pic if you give multiple!


indeed in the repo JSON the preview pics are supplied in the order that they were in the PXML which as far as im concerned is the best way to do this, on the repo website however its in reversed order but this does not affect any PND managers or minimenu this only affects the app details page on the website.


I can change the website to show in descending order instead if you like but as i said still will not fix what porg has highlited as a problem.
 
Do you see now, that I am not an impolite person, but someone who wants to contribute?
I never said at any point that you were impolite or rude. I just stated that your input didn't need to be said on the Repo. You had said it on the forums (in at least one other topic too) and I had read it. The way it was stated on the repo was also more than a language problem - it is one of simple netiquette. But that never was the issue.


I do not have access to any other forms of viewing whatever appears on the repo. Period. I don't now. Never have and likely never will. Therefore I am not able to see what does and doesn't work or isn't shown other than the repo. If something is one way on the repo and another way in another piece of software that shares the same info, then that is not my issue or anything I can sort out.


The message on the repo was directed specifically to me - this could have been done in a PM (and to be fair I should have addressed the issue to you via PM). But you'll never see my point, so there's really no sense in continuing this discussion.
 
iprice, I understand your point now. You seem to not have a Pandora on your own, just developed the game for it (on another platform), so your only visual interface to PNDs was through the repo website. And from this POV you made everything right, and did not understand "what does this porg guy want".


I on the other side, as a user who experienced PND listings & overviews through various visual interfaces, noted that the implementations of previewpics presentational software (not your responsibility!) do in fact use primary pictures, whereas the PXML previewpic standard does not define a primary picture, and because of that gap between theory and practise, some content may never be seen by users.


I published this issue to a general developer audience (wiki + forum), and notified some affected maintainers. Not with the message that "the maintainers made something wrong", but just to inform, that they are affected from something, which is yet only loosely defined (PXML previewpic), but that nevertheless within that situation, there is a possibility to influence what is shown as the primary picture.


From my side, it is sorted out.


From the PXML team, I hope that they will define a way to reliably set a primary pic, as many presentation contexts only use 1 pic. To get this process started, I wrote the recommendation to the PXML wiki. May experts please follow up and revise it. The easiest would be to define that the image with the filename, which is first in a normal lexicographical order, IS the primary picture, as this is the way most softwares implemented it. I don't see the need for an explicit primary-flag. Just do define the de facto standard as the de jure standard.


And from maintainers who have goodwill meanwhile, they can set an illustrative pic as the de-facto primary pic (first in source code and a filename which makes them first in a normal alphabetical sorting).
 
What is so bad about the image listed first in the list being the "first" image to be displayed? If all implementations of programs just followed this everything would be fine and golden, nothing extra to specify. Don't go via lexical sorting and stuff, just make the programs to follow the PXMLs order.
 
What is so bad about the image listed first in the list being the "first" image to be displayed? If all implementations of programs just followed this everything would be fine and golden, nothing extra to specify.
I consider this to be a good standard.


A standard per se must be nothing technically complicated, just something to agree on, publicly documented and accessible.


Simple is even better. And some accompanying explanations and examples help as well.

Don't go via lexical sorting and stuff, just make the programs to follow the PXMLs order.
I agree that the standard should not contain this as a rule, only as an additional recommendation, because the standard defining body is aware, that some implementations may "loose" or not know the previewpics' PXML source code order, and then resort to lexical order.


The only remaining task: Those within the OpenPandora community, who have the competence/authority to alter the standard, please do so. Thanks!
 
Last edited by a moderator:
Wow, why is this an aggressive thread? (I'm only read the first page so far)


As one of the guys who defined the whole pnd and pxml spec and writes minimenu, perhaps I really should be better supporting multiple screenshots in minimenu's interface. Its certainly okay to make requests or even requests against the specs.


Mounting and unmounting to extract screenies is slow (and I generally turn them off myself which maybe leads to me forgetting ;) , but once mounted to get one screeny.. I shoudl just grab the rest; the actual copying the screenshots is generally trivial (they're small files usually), relative to the whole process.


So don't make decisions with regards to minimenu, since minimenu should be showing more I imagine.


(We didn't define a 'primary' screenshot in the spec IIRC; the order of them in the pxml is important 'de facto', but not really a standard; who knows what order an app will show them in?)


I think a request to add them to minimenu is okay, nothign to be angry about :)


jeff
 
As I have 7 comments from Porg on my ports, I may as well say something here too ;D


I did find the tone a bit offensive, and I really would have preferred some kind of private communication first. But I find Porg implication in making things better a good thing.


I think a forum thread in the Dev section before spamming repo would have been a better procedure, allowing for discussion on the technical solution.


I really think is up to the clients (minimenu, PNDManager, etc...) to handle correctly that kind of stuff (if screen estate is a problem, just slideshow the previews).


I'm gonna follow the firmware-dev ML and do what's recommended there.


Clop'
 
I agree with your communication theory analysis, and would be delighted, if you could revise the recommendation concerning previewpics at the wiki accordingly.
It's not really a "theory", just a logical analysis.


I wish I had more than ~24 hours a day for fixing things, but that is not the case. This is why instead of updating the previewpics I decided that my contribution should be about the design of such recommendations instead, because the way I see it running after people who have not understood the problem has very low efficiency (==is expensive in regards to its consumption of time).
 
As one of the guys who defined the whole pnd and pxml spec and writes minimenu, perhaps I really should be better supporting multiple screenshots in minimenu's interface. Its certainly okay to make requests or even requests against the specs.

Speaking as one of the guys that still can't get minimenu to turn the damned screenshots off (and the annoying freeze that occurs while they load), can I request you fix that instead? :)


D.
 

horror-of-dracla-cushing.jpg
 
OK... I am going to really TRY to update my PNDS and the preview shots. I have already used Gruso's snap snap to take the previews... just a case of refactoring my PNDs and reuploading.
 
@Green7 & Lurkio, let's not go down the path of name calling and image posting, especially in the dev forum. Thx :) (Besides, I don't think porg is anything like Chad!)
 
Speaking as one of the guys that still can't get minimenu to turn the damned screenshots off (and the annoying freeze that occurs while they load), can I request you fix that instead? :)

MiniMenu instructions:


To toggle the previewpic: Press action key "A".


To permanently hide the previewpic display:


Press SELECT to bring up the MiniMenu submenu > Configure Minimenu > General Options > Detail panel on start : NO.


On boot it will then be hidden, but on demand you can still toggle via action key "A".
 
OK... I am going to really TRY to update my PNDS and the preview shots. I have already used Gruso's snap snap to take the previews... just a case of refactoring my PNDs and reuploading.

Great! You are the first maintainer who publicly supports the idea for primary/ordered previewpic(s). Thanks! :)
 
Speaking as one of the guys that still can't get minimenu to turn the damned screenshots off (and the annoying freeze that occurs while they load), can I request you fix that instead? :)

MiniMenu instructions:


To toggle the previewpic: Press action key "A".


To permanently hide the previewpic display:


Press SELECT to bring up the MiniMenu submenu > Configure Minimenu > General Options > Detail panel on start : NO.


On boot it will then be hidden, but on demand you can still toggle via action key "A".

Yes, I know. It doesn't work if you have any theme but the default installed.


D.
 
@skeezix (And anyone else interested):


Just had an idea, but why not keep the preview pic outside the disk image, why not just append it/them instead? then when parsing the pxml file, grab them in order of appending (or go by some tag, like PIC1).


Shouldn't this speed up the whole loading process in mini-menu, since you wouldn't need to mount/dismount the pnd?
 
Back
Top