Pandora How can I use different icons in one PND file?

[jgeiss]

Hi there,

if I build a PND file with pnd_make.sh -d dir -p file.pnd -c -i icon.png -x dir/PXML.xml the resulting file is a squashfs file with the file PXML.xml and one icon icon.png added. The menu shows the icon and I can start my application.

Now I want to have two different applications (which depend on each other) in my PND. Each one should have a different icon.

How can I add two icons? Using cat >>file.pnd icon2.png does not work.

Thank for any help.

 

[sebt3]

short answer : you cannot

long answer : implement it yourself

(yes the long answer 1 word longer )

 

[TrashyMG]

It can't be done with pnd_make.sh script, you would need to modify/generate the PXML file yourself and add another application to the XML, there you can specify a different icon image.

The PXML specification wiki has some Examples that may be helpful, I believe the full-sample show two applications specified in the PXML with separate icons.

 

[thatgui]

I believe the full-sample show two applications specified in the PXML with separate icons.

jupp every "application" node has an "icon" node:

...

<application id="sample-app2" appdata="sample-app1">

...

<icon src="my-icon2.png"/>

...

</application>

 

[ptitSeb]

Only solution I have found to have multiple Icon, for now, is to have multiple PND.

That's what I have done with the LibreOffice launcher. I have the Main PND, which is LibreOffice, that have only 1 icon (and only 1 entry in the menu). Then each individual launcher has is own Icon and menu entry. The only job of the launcher is then to mount LibreOffice PND and launch the app.

I can provide shell code snippet if you are interested in this method.

 

[TrashyMG]

PtitSeb is correct, even though the PXML specifications indicates that two or more icons can be set by adding an icon tag for each application block.. it seems to only use the first one specified. I made a test PND as a trial.

This seems like an oversight in the PND system..

Edit: even in Minimenu, it doesn't seem to make use of the second icon declared in the PXML..

 

[milkshake]

No, what actually happens (for speed):

The icon that is used in the menu and desktop is taken from the end of the pnd file, and since you can currently only append one png file to the end of your pnd archive that's the one it uses.

The only way this will change is if another method is implemented.

It should be possible to extract the icons from the archive assuming the firmware includes the right tools but this will likely sacrifice speed (of building icons from pnds found on the SD card).

 

[_wb_]

If we make a revision of the PND file format, it should be an ar or tar file instead of just a concatenation of stuff. It shouldn't be impossible to mount a squashfs that is inside a tar, and accessing the PXML and icon(s) and whatever other metadata we want to put in there should be easy (even from within a shell script).

 

[milkshake]

Not impossible but also not fast like it is now. ( people have a lot of pnds on their SD cards )

 

[_wb_]

Not impossible but also not fast like it is now. ( people have a lot of pnds on their SD cards )

Why would it be any slower? How is the file offset computed now to find out where the icon starts? How would it be computed if we would use something like tar? Unless I'm missing something, I don't see any significant difference.

 

[milkshake]

The icon is the last thing at the very end of the pnd easy to find nothing to extract from the pnd itself, always in same place for every pnd.

 

[_wb_]

The icon is the last thing at the very end of the pnd easy to find nothing to extract from the pnd itself, always in same place for every pnd.

So how do you actually find the offset where the PXML and PNG start? Read the squashfs header to find out how long it is so you can skip it, or read from the back of the file backwards until you find a PXML/PNG header? It has to be one of those two, and I don't think it would be any slower to use some kind of tar format instead.

If you really want to minimize the number of seeks/read operations, you have to put the icon first.

 

[thatgui]

or read from the back of the file backwards until you find a PXML/PNG header?

Don't know how the pnd deamon does it, but I did it like that back then in my dosbox-pnd-creator thingy. Its quite fast, at least a lot faster then mounting the squashfs file and getting the icon - can't compare it to tar file usage though. But afaik tar uses compression and you can't access file randomly, so would it really be faster ?
Edit:

Does it really make a difference wether the icon is put at the beginning or at the end ? Isn't it just about where you start to look for it ?

 

[_wb_]

or read from the back of the file backwards until you find a PXML/PNG header?

Don't know how the pnd deamon does it, but I did it like that back then in my dosbox-pnd-creator thingy. Its quite fast, at least a lot faster then mounting the squashfs file and getting the icon - can't compare it to tar file usage though. But afaik tar uses compression and you can't access file randomly, so would it really be faster ?

Edit:


Does it really make a difference wether the icon is put at the beginning or at the end ? Isn't it just about where you start to look for it ?

Tar does not use compression. It's just a way to glue files together into one big tarball. You can then gzip or bzip2 or xz or use whatever compression you want on the tarball, so you get a .tar.gz or a .tar.bz2 or a .tar.xz file. I propose to not use compression because that is an unnecessary complication/slowdown and the squashfs and icon are compressed already anyway.

Reading from the beginning is faster than reading from the end until you find something, because the former is just one read operation while the latter are multiple reads plus some kind of grep -- and theoretically it's not safe, because there could very well be a string "<PXML>" inside the icon PNG file by pure bad luck, and then what?

 

[thatgui]

Tar does not use compression. It's just a way to glue files together into one big tarball. You can then gzip or bzip2 or xz or use whatever compression you want on the tarball, so you get a .tar.gz or a .tar.bz2 or a .tar.xz file. I propose to not use compression because that is an unnecessary complication/slowdown and the squashfs and icon are compressed already anyway.

double :facepalm: for me, did not read the wiki article right, so no compression, but you still need time time to get the icon out > Is the time/resource spent on finding and extracting a certain file constant or does that scale with the size of the tar ?)

Reading from the beginning is faster than reading from the end until you find something, because the former is just one read operation while the latter are multiple reads plus some kind of grep

But you don't know the length/position of both, the icon and the pxml, so you have to read chunks nevertheless (?)

and theoretically it's not safe, because there could very well be a string "<PXML>" inside the icon PNG file by pure bad luck, and then what?

Highly unlikely, but as you said theoretically possible.
But don't get me wrong, I don't want to start a discussion about a topic, I don' really have any real knowledge in. I'm just curious, thats why I'm asking stupid questions.

 

[_wb_]

Tar does not use compression. It's just a way to glue files together into one big tarball. You can then gzip or bzip2 or xz or use whatever compression you want on the tarball, so you get a .tar.gz or a .tar.bz2 or a .tar.xz file. I propose to not use compression because that is an unnecessary complication/slowdown and the squashfs and icon are compressed already anyway.

double :facepalm: for me, did not read the wiki article right, so no compression, but you still need time time to get the icon out > Is the time/resource spent on finding and extracting a certain file constant or does that scale with the size of the tar ?)

In the case of tar I think it's just a header per file that gives the filename and size and attributes. So extracting a given file requires to skip over files you're not interested in. Since the number of files is small (e.g. 3: one squashfs file, one icon file, one PXML file), it does not matter much which order they're in, in the worst case you'll have to do N-1 redundant seeks if you're interested in one out of N files. If we put e.g. the squashfs file first, the offset for that one is fixed (so we can immediately seek to the right position), the offset for the icon file can be found by looking at the size of the squashfs file, etc.

Reading from the beginning is faster than reading from the end until you find something, because the former is just one read operation while the latter are multiple reads plus some kind of grep

But you don't know the length/position of both, the icon and the pxml, so you have to read chunks nevertheless (?)

Well I propose to use an actual wrapper like tar, not just concatenating files. It will tell you how long the files are so you know where to seek to.

 

[Ziz]

Well I propose to use an actual wrapper like tar, not just concatenating files. It will tell you how long the files are so you know where to seek to.

Isn't it too late for the pandora now to change the PND format?

 

[Neelix]

Not at all...  one would just need to update libpnd to deal with both versions of the format, and make the upgrade available via the update Pandora OS tool.  (milkshake would need to update the repo to deal with the new format too of course)

- Neelix

 

[_jr_]

I suspect it has to be made sure that the squashfs starts on a page boundary (or something) to allow efficient mounting without unwrapping the container. I'm too stupid to fully make sense of the tar and cpio manuals but I suspect these formats don't support that.

 

[Ziz]

Not at all... one would just need to update libpnd to deal with both versions of the format, and make the upgrade available via the update Pandora OS tool. (milkshake would need to update the repo to deal with the new format too of course)


- Neelix

And on unupdated Pandoras an error occurs and no hint to upgrade the OS to get the new PNDs working. All this just for little pictures?