PND criticism


Offering the download in a technically inferior, but easier to handle, container will look, to Johnny, as if someone tries to help him. Apologising that for this app it isn't, unfortunately, possible, will look like someone really tried. Telling Johnny that he really ought to search the forums, and the pnd spec is open so RTFM, makes Johnny return his Pandora.

But is it really worthy all the effort? If Johnny don't ask on forums or don't read the specs he wouldn't know what is this Z-version for and even if he chooses it by any chance how could he know he could open it with his favorite zip application? And even if he guess it's a zip he could only open pnd but not create or modify one, because he wouldn't know he have to add pxml and icon at the ond of the file.


So instead of reimplementing pnd_tools, appstore and so, only to allow Johhny NQJUser opening pnds with winzip isn't it easier just tell newcomers to use WizardStan's tools?
 
Skeezix: I know. I thought it might be doable for small apps, but on second thought that would probably lead to "Whaa, my app isn't working when I'm running this other app too - It says the RAM is RAMMED or something, so I'll RMA"...Unless that could be mitigated some other way (some gnarly swap solution?).


Still, I believe in the set of simple windows tools, and ED: Yes, you might be able to hack something together if you had time. But isn't there someone out there with enough skill and a little more time on their hands? Also: Information Architecture.

Well, you don't need that much skill.


Basically, you'd just need to code a small Windows GUI.


You select a PND (or use drag'n'drop or a file association), select where to extract it and then the GUI could use existing command line tools to extract the PND.


Same for compressing: You select a directory and a PXML, give the PND a name, select the compressor (ISO or squashfs right now) and then the GUI could use command line tools to create it.


You only need a GUI that asks the user simple questions and uses command line tools. That's it.
 
Anyone else find all this talk of Johnnys a bit condescending? As in, maybe, just maybe, someone who can figure out how to buy a little-known computer online isn't a complete imbecile and can also figure out the concept that you need a special program to look inside PNDs? Especially if that program is really simple to use?


And maybe it's a little late in the game to switch from PNDs to ZIPs now?


And now because of all this needless drama, EvilDragon has one more task on his already overloaded plate.


Not that it's not a worthy task, but some of ED's recent comments have worried me. He seems a little burned out.
 
Last edited by a moderator:
Anyone else find all this talk of Johnnys a bit condescending?
it all seems like bonkers to me.


i am really surprised that this is causing as big an issues as it is. the pnd format is an elegant solution to the pandora's NAND space issue. there is still room for it to be worked on but it is still perfectly useful. i do not understand how creating an SD with 3 or 4 folders is remotely challenging to the basic user, and for more technical users they dont have to pay any attention at all and just do their own thing. if it goes wrong then they can just reflash. not only that but the whole space issue can be circumvented altogether by just running from SD.


as a basic user myself, the folders on an SD thing is by far more straightforward than trying to work out what is going on under the hood in linux. if someone said to me "oh just stick it in the root folder" that would just cause me to ask a huge number of other linux related questions. it is even more confusing for someone who may be used to windows.


i can understand the confusion around not being able to crack open a pnd so that sounds resolved, but really, once that has been resolved, i really dont see why we are jabbering on about it. just stick some instructions in the little manual and move on to something more worth talking about.


i find it frustrating how people argue about stuff on here. it feels like such a waste of potential talent when really, if you have an idea of way for things could or should be then you should just do it. announce it and if people like your way of doing things then they will pick it up. we seem to have this hugely hostile attitude over "the official way to do things" but i think that is a really uncreative attitude. the software is open, so stop obsessing over closing it down. the PND format, is an elegant solution as an option for the most general of users but it isnt the law and the sooner people stop treating it as such the better.
 
And maybe it's a little late in the game to switch from PNDs to ZIPs now?

You don't need to switch.


PND is a standard we created supporting multiple compressions. Right now, it supports ISO and squashfs (though most use squashfs).


Adding ZIP wouldn't break anything - but I doubt the devs would use it very much.
 
I figure Johnny is generally as computer savvy as I am. Only, he hasn't lived on these boards för the last 2,5 years. I have, and that means I know that the information is out here somewhere. Even I, though, have trouble finding stuff exactly like that - How do I mount and look inside a pnd? Also, Johnny lives on a windows box, not a linux box. That means another layer of confusion, since you have a quite different way of dealing with unknowns depending on your OS.


It may well be easy to create a bunch of folders, but you'd be amazed at the amount of students I get - and I teach Comp Sci - who simply has no idea of stuff like folder structure. Nowadays, there are already folders for "documents" and "downloads" and whatnot. All common apps have defaults sensibly set, and when you click on "my computer" or whatever, all you need to do is remember if you want a Document or something you Downloaded. These are people who would self-identify as computer savvy. These are the people the pandora needs to sell to, in order to be successful - Young, sligthly nerdy, people with a disposable income.


In short: Those of you who believe that this is an easy problem to solve are very, very blind to the amount of info you have already internalized. And if Craig and ED are ever to recoup their losses, the pandora needs to be understandable to people outside the boards, since us on the boards are quite a small (and well saturated) market.
 
tbh, in my opinion Johnny isn't going to give a hoot what format the application is in, as long as it works. Anyone who is looking to tinker will invariably read at least some of the documentation. Thinking that you can just jump in and start hacking around is very naive. In my view anyone looking to hack about with PND files will have some kind of technical background, in which case they will not have any real problems with doing a bit of light reading to fill in whatever blanks they have. The apparent majority we are hearing about, the ones that are all iPhone users and have no clue what so ever, will not be looking to disassemble application archives. They will be plonking them onto their SD cards and will be happy running them. In summation my view is that the following things should be looked at, and I will help out if required.


1. Easily located (maybe on device?), extensive, PND documentation. Basically what is already on the wiki.


2. Better GUI based tools (ED has already addressed this, these tools are in the pipeline) for Windows/OSX users, or users who simply prefer their use over the command line. These tools should cover, in my eyes. PND viewing, editing, creating and extracting. Preferably in a single 7-Zip style GUI. Also giving the developer the choice of compression (be it zip, ISO or sqashfs).


I think that all this talk of changing formats and basically starting again with software is stupid. Give options, if zip support can be added to the PND format then I'd say add it. You lose nothing from adding it, even if no one uses it. At least the choice is there.
 
You don't need to switch.


PND is a standard we created supporting multiple compressions. Right now, it supports ISO and squashfs (though most use squashfs).


Adding ZIP wouldn't break anything - but I doubt the devs would use it very much.
Adding ZIP wouldn't help either. You can add an additional format but many devs will continue to use the superior format anyway. By adding yet another type of archive you only complicate matters (as you have no idea what type of container you are looking at) and delay development of good tooling.
 
heard of winZip? heard of winRar?


what we need is winSfs a visual app for windows/linux/mac that functions the same as winzip or winrar.


of course this would need coding.. perhaps there is already a frontend for squashfs-tools that already exists...


thats all we would need to appease people.
I don't it's worth the time, when there isn't a use case for ordinary users to want to repack squashfs files. Plus, 7-zip already has unpack-only support for SquashFS on Windows.
 
I'm getting to a point where my BASIC interpreter will be available for Pandora pretty soon. Which means that I'll likely be creating a PND for it - and as I'm predominantly a Windows developer (though I build the Pandora build in linux, I do it in a VM these days) I will likely write myself a small Windows GUI for the PND tools. Might as well develop a complete "PND Studio" while I'm at it, so you can pencil me in for that job.


D.
 
Problem is simple - as always -


Community project, community needs to do the work; but no one steps upm:)


Many assume 'surely someone has the skils...'


But step forward :)


Jeffphone
 
I'm getting to a point where my BASIC interpreter will be available for Pandora pretty soon. Which means that I'll likely be creating a PND for it - and as I'm predominantly a Windows developer (though I build the Pandora build in linux, I do it in a VM these days) I will likely write myself a small Windows GUI for the PND tools. Might as well develop a complete "PND Studio" while I'm at it, so you can pencil me in for that job.


D.

Are you serious with that? (just asking to be sure and because of your previous Windows-related comments ;) )


Because I already started working on one... kind of anyway.
 
I'm getting to a point where my BASIC interpreter will be available for Pandora pretty soon. Which means that I'll likely be creating a PND for it - and as I'm predominantly a Windows developer (though I build the Pandora build in linux, I do it in a VM these days) I will likely write myself a small Windows GUI for the PND tools. Might as well develop a complete "PND Studio" while I'm at it, so you can pencil me in for that job.


D.

Are you serious with that? (just asking to be sure and because of your previous Windows-related comments ;) )


Because I already started working on one... kind of anyway.

Actually, yes - IIRC you code in Delphi, and so do I. I have a strict ruleset I use so I can also compile for linux under Lazarus so I could conceivably build for both platforms... But if you've started on one, then have at it - it's one less job for me and this interpreter is taking up all my time as it is!


D.
 
Actually, yes - IIRC you code in Delphi, and so do I. I have a strict ruleset I use so I can also compile for linux under Lazarus so I could conceivably build for both platforms... But if you've started on one, then have at it - it's one less job for me and this interpreter is taking up all my time as it is!


D.
Yep I am using Delphi.


I would love to see a project of yours to get to know that ruleset as I always wanted to look into Lazarus programming.


Also I can make the code public if you want me to, so you can have a look at it and maybe we can share some ideas. (prefer GIT or SVN?)


I am planning to use a Tree for the PND visualisation on which you can simply drop files and folders. Separate edit boxes will be used for the image and the PXML (eventually I could add a "PXML Creator" which presents you with a GUI to edit all the necessary values of the PXML))


I am using the VirtualStringTree class for said tree view, I suppose it should work with Lazarus.


Oh btw, not that I have too much time at my hands ;) but I love some GUI design in-between as a change.
 
Last edited by a moderator:
Actually, yes - IIRC you code in Delphi, and so do I. I have a strict ruleset I use so I can also compile for linux under Lazarus so I could conceivably build for both platforms... But if you've started on one, then have at it - it's one less job for me and this interpreter is taking up all my time as it is!


D.
Yep I am using Delphi.


I would love to see a project of yours to get to know that ruleset as I always wanted to look into Lazarus programming.


Also I can make the code public if you want me to, so you can have a look at it and maybe we can share some ideas. (prefer GIT or SVN?)

For version control, I'm a real fan of ZIP and RAR rather than GIT and SVN :) I've never used any sort of source-control.


As for the ruleset - you're free to use anything that comes entirely from Delphi's basic component set and avoid using anything that's windows specific. Hence DWORD types are LongWords etc. One gotcha is how FPC under ARM handles the Extended type - on x86 it's 10 bytes in memory, on ARM it's only 8 (the same as a DOUBLE type). This only has an effect if you save or load a floating point value in byte format to disk rather than for in-app usage.


My interpreter is written in pretty much pure object pascal with only very minimal actual Delphi code, so it's a breeze to compile for linux.


You can get the source for it here: http://www.zxspectrum4.net/forum/viewforum.php?f=6 which has both linux and windows builds available. Pandora PND is a way off yet :) The source might be of use to you to see how the linux and delphi versions differ.

I am planning to use a Tree for the PND visualisation on which you can simply drop files and folders. Separate edit boxes will be used for the image and the PXML (eventually I could add a "PXML Creator" which presents you with a GUI to edit all the necessary values of the PXML))


I am using the VirtualStringTree class for said tree view, I suppose it should work with Lazarus.


Oh btw, not that I have too much time at my hands ;) but I love some GUI design in-between as a change.

Yeah, that would be neat. Also a small section for preparing an SD card would be quite nice - I wrote some code a while ago for identifying and accessing USB drives/devices from Delphi which might be of use.


D.
 
For version control, I'm a real fan of ZIP and RAR rather than GIT and SVN :) I've never used any sort of source-control.
Sure, that works, too. Just send me your mail in a PM and we can stay in touch.

As for the ruleset - you're free to use anything that comes entirely from Delphi's basic component set and avoid using anything that's windows specific. Hence DWORD types are LongWords etc. One gotcha is how FPC under ARM handles the Extended type - on x86 it's 10 bytes in memory, on ARM it's only 8 (the same as a DOUBLE type). This only has an effect if you save or load a floating point value in byte format to disk rather than for in-app usage.


My interpreter is written in pretty much pure object pascal with only very minimal actual Delphi code, so it's a breeze to compile for linux.


You can get the source for it here: http://www.zxspectru...ewforum.php?f=6 which has both linux and windows builds available. Pandora PND is a way off yet :) The source might be of use to you to see how the linux and delphi versions differ.
Thanks, I will have a look at it. Those rules also sound kind of my own guidelines, I use standard Delphi types wherever possible and WinAPI (or any api for that matter) calls only if it is really necessary.


I guess most of my apps should convert to Linux pretty fine then, I just never gave it a shot.

Yeah, that would be neat. Also a small section for preparing an SD card would be quite nice - I wrote some code a while ago for identifying and accessing USB drives/devices from Delphi which might be of use.


D.
Not sure what you mean by "preparing an SD card", do you mean creating the "pandora", "menu" and "desktop" folders to put the PNDs in?


If so, is that really necessary?


Also, because I just got that working, I think drag and drop is kind of tricky, cross-platform wise.


I currently use the IDataObject type, which is defined in ActiveX, which I assume is not cross-platform safe, is it?


The only other method I know of involves windows messages, which kind of have the same problem...


But I will add manual buttons anyway, and encapsulate the drag&drop functionality so worst case I just have to disable that part for Linux.
 
One thing you might consider is the use of callbacks. I define a procedure type in delphi, say:



Code:
Type


  TMyProcType = Procedure(myvar: mytype);


Var


  MyCallBack: TMyProcType;


And then have a linux-specific and Windows-specific unit which has platform-specific procedures that match the TMyProcType declarations in them, then at runtime assign MyCallBack := linux-proc; or MyCallBack := Windows-proc; then when you need that procedure you just call MyCallBack. I do this for various operations that can't be made platform-agnostic and it seems to work well, and FPC supports them nicely. BTW, getting Lazarus to build ARM binaries is a bitch.


D.
 
Note that a pnd may be more than one application ..


I see two modes - a pnd explorer that opens any old random pnd (mount or unpack, view, alter, repack) and pnd project builder (wherr you add bits in and save a conf file out so can just hit rebuild button to repackage later)


Jeffphone
 
Note that a pnd may be more than one application ..


I see two modes - a pnd explorer that opens any old random pnd (mount or unpack, view, alter, repack) and pnd project builder (wherr you add bits in and save a conf file out so can just hit rebuild button to repackage later)


Jeffphone

I don't see why those two "different" modes could not be combined. Eventually a PND is "just" a bunch of files compressed as ISO or SquashFS with an icon and PXML.xml file attached to it.


Now, sure the xml file may specify multiple "applications", but the builder program does not need to care for that, apart from the fact that it should parse the xml file and check whether the mentioned applications (and their respective icons) are present in the list of files added to the PND.


In this scenario it does not make a big difference to have a PND with one or multiple applications.


Now if the program should be able to also provide a GUI for PXML creation this gets a tag more complicated, but not so much imo (also first version will not have this and only allow for simple PND packing and unpacking).


But your config file idea, still is good and I think I will add that feature to the todo list.


foxblock out
 
Last edited by a moderator:
To put my two cents in, I support the idea of making better tools for working with PNDs rather than changing the compression format to functionally inferior zip. I don't like the idea of making several versions of (some) PNDs just to make them easier to open with popular tools. Sounds like an unnecessary and less than optimal hack to compensate for the lack of easy tools and further complicates the PND system to regular users who are not interested in opening their PNDs. The only people this would help is the in-between people who are curious about the content of their PNDs, but not savvy enough to look for information. I think catering to this particular audience is not enough reason for complicating the system for everyone.


The best tools for the job are not always the easiest, but they are still the best. User friendliness can be improved, but technical limitations can't be lifted.
 
Back
Top