Release Pxml Fileformat V1.5

[lulzfish]

There's going to be moaning, but some of the things that have been said are valid, especially about the pic preview tags.

It's good that you published this early so people could take a look at it.

 

[PoisonedV]

how, lulzfish? It doesn't ask how many languages you are going to have or anything else like that. It doesn't seem like it would be hard for the library know when to stop.

 

[dflemstr]

how, lulzfish? It doesn't ask how many languages you are going to have or anything else like that. It doesn't seem like it would be hard for the library know when to stop.

I'm sorry, but the issue isn't performance. It is about having a 'predictable' file format.

An analogy:
Compare the current PXML structure to ".doc"-files, and a 100% compatible standard to... ".odf"-files.

As many of us know that have worked with ".doc"-compatible programs other than MS Word, some things don't look the same in Word as in those alternative, compatible programs. This is because the ".doc"-format has alot of exceptions and is generally messy (a ".doc"-File contains a whole file system, like NTFS or ext3, but less advanced :S).
Sure, it is fast to load, and the files are small. Problem is only, that only MS Word can open the files correctly.

Compare this to ".odf"-files. They use an open standard based on zip-compressed XML-files. This ensures that all .odf-compatible programs can open the file equally well, without excpetion.

Get the problem now?

 

[PoisonedV]

No, I realize it needs updating overall, but I was just referring to Lulzfish's point about declaring how many of something,.

 

[lulzfish]

Exactly what I was getting at. libpnd might be able to open these fine, but if you go a little bit further to make it XML-compatible, it will be that much simpler to work with.

edit: I don't know about languages, but i think the indices on the pic tag were unnecessary.

 

[emcp]

would there be any chance on using svg, instead of png
it just menu would then be restricted to the icon size and style etc.
svg is easier manipulated, and can lower the file size

thanks

 

[dflemstr]

SVG is difficult to render, tho. You have tho have support for animation etc. But further development discussion about this topic belongs in the General section, not here.

@ PoisonedV Sorry, read your post too quickly. I have already opened VIM and started covnerting some code XD, so I'm kinda busy

 

[lulzfish]

Oh yeah, nobody answered me about animated PNG support. I'm going to assume it's not supported whatsoever?

 

[dflemstr]

APNG is a relatively new standard; I don't know if it's implemented in libpng yet or not. The thing, however, is that if you want animated images in an application, you have to change more than just the loader. Even if we could load an APNG image, it wouldn't move since more code is needed to implement animation.
Anyways, go to the Dev forum and ask for APNG support or something, I might have missed something

 

[lulzfish]

Oh, yeah. Why would I have asked about that here? It's completely unrelated. :blink:
But anyway, SVG might be interesting, but the file format really comes down to whether or not the menu program supports it.

 

[Kramy]

OK, I'm sorry to have brought this up in the way I did. It's just that I have used alot of application frameworks and utilities that use XML. XML is there for a reason, and that is that it should be possible for any application to use the data provided by the XML file, and making it easy to use a format.

I do not see what I said as moaning. I only tried to highlight problems that will happen, sooner or later, because the PXML format has alot of problems. (For example: What happens with multiple standalone tags? What if you want to associate the app with MIME types and not only extensions? How does the format handle encodings other than UTF-8 (for languages other than english)? etc) This rises alot of problems for a programmer, and for someone who would like to write a PXML file.

You make some very good points, and I think your proposal is more "proper" than the way it is going to be done.

But it doesn't matter. lib_pnd is available for use, and the issues you brought up(like the one below) can be handled by a more lenient or smarter parser.

1. You use specific tags for language instead of "xml:lang". This means that the menu program needs to know ALL the ISO codes in the world and look for them just to translate the menu.
Proposal: Instead of "<description><de_DE>....", PLEASE use "<description xml:lang="de_DE">...."

There is no reason it has to know all the possible ISO codes. It simply has to look in <description> for a tag with a language matching the one currently used on the Pandora. Easy peasy.

Current user is on "en_UK" - look for "en_UK"; no "en_UK" found; look for "en_"; found "en_US".

I could volunteer to not only make a format that is compatible across all platforms, fully XML compatible, with a XSD spec, and with a C library function (no library needed) that can parse this file and give the result as a struct. Anyone else in the community could of course help with this.

We could even make it like this: The current PXML format continues to exist, until I release the new version (in max 3 days or so), and if I don't make it, I will stop complaining and just accept the current format.

What does everyone think about that?

I'm inclined to say... if it works currently, leave it be. It's just personal preference. For many people, less symbols is simpler, and xml:lang="en_US" is more complex than <en_US></en_US>


I have a bit of experience with XML parsers - not proper ones, though. I wrote a lenient/smart one a few years ago. It can read any compliant XML files, but it also supports one additional feature:

non-escaped tags.

CODE
<smartxml>
<explanation>Use the <explanation> and </explanation> tags to enter an explanation.</explanation>
<explanation>Do not forget to include the closing tag, </explanation>
</explanation>
</smartxml>


Unfortunately, nothing else could figure the files out, so I ended up adding escaping to my XML writer. (which the reader handled fine too - fully compliant. )


For image-flipping previews, I'd do something like this:
CODE
// Flip pictures every 6 seconds.
<preview repeat="yes" time="6000">
<pic>Pic_01.png</pic>
<pic>Pic_02.png</pic>
<pic>Pic_03.png</pic>
</preview>

CODE
// Short Animation, wait 6 seconds, another short animation
<preview repeat="yes" time="6000">
<pic time="20">Pic_01.png</pic>
<pic time="20">Pic_02.png</pic>
<pic time="20">Pic_03.png</pic>
<pic time="20">Pic_04.png</pic>
<pic time="20">Pic_05.png</pic>
<pic time="20">Pic_06.png</pic>
<pic time="20">Pic_07.png</pic>
<pic>Pic_08.png</pic>

<pic time="20">Pic_11.png</pic>
<pic time="20">Pic_12.png</pic>
<pic time="20">Pic_13.png</pic>
<pic time="20">Pic_14.png</pic>
<pic time="20">Pic_15.png</pic>
<pic time="20">Pic_16.png</pic>
<pic time="20">Pic_17.png</pic>
<pic>Pic_18.png</pic>
</preview>

I don't care how image flipping is implemented, but it would be useful to have.

 

[lulzfish]

I don't know if you need such fine control over image-switching, that might make menu programs complicated.
It might be easier to just have something like <preview base="pic" ext=".png" num_pics="15"> and then "pic0.png", "pic1.png" ... , "pic13.png", "pic14.png". No need for double-digit number of preview images, but just as an example for formatting.

Menus that don't support animated previews could just use $base + 0 + $ext for "pic0.png".

 

[Kramy]

I don't know if you need such fine control over image-switching, that might make menu programs complicated.

If they don't want to support animation, just jump to the first pic without a short time specified.

You call it "fine control" - I call it "simpler". It's very easy to see how it works, while your suggestion is slightly more subjective, and means more work for the developer.

Examine:
<preview base="pic" ext=".png" num_pics="15">

I would assume it would handle pic_001.png and pic_01.png and pic_1.png the same - which makes me wonder what sort of conflict resolution or lenient naming it has. Is it zero-based or 1-based? What's the exact format of the "_xx" it increments? After deciding how it would resolve such conflicts or details, and documenting them, it may have just been easier to go with "simpler", since you also get "fine control" as you pointed out. I like formats that anyone can open in a text editor and understand - not ones that require consulting the documentation to figure out how exactly something works. If someone can open an existing PXML file and change it for their own game without consulting any documentation, then it's simple enough.

Heh... this reminds me of old Basic-like languages.
CODE
// Too Simple - needs improvement
IF a == 2
a = 1
ELSE
a = 2
ENDIF

// Better
IF a == 2 THEN DO 1
a = 1;
ENDDO
ELIF a == 1 THEN DO 1
a = 2;
ENDDO
ENDIF

My motto - KISS! Less symbols, less stuff that requires documentation. The final xml document should have visual patterns in it that make it easy to read and figure out.

But again, that's just my opinion.

 

[dflemstr]

There is no reason it has to know all the possible ISO codes. It simply has to look in <description> for a tag with a language matching the one currently used on the Pandora. Easy peasy.

Current user is on "en_UK" - look for "en_UK"; no "en_UK" found; look for "en_"; found "en_US".

Well... in theory, what you say works. However, what if no en_-languages are available (or a better example would be: what if you rsystem is "de_DE" and there are no "de_"'s?)?
What do you do then?
And btw, look at the code like it is now. (git://git.openpandora.org/pandora-libraries.git)
It is exactly like i said, the parser searches for "<en>"-tags and adds that to a field... I intend to change that if i may/can.

I'm inclined to say... if it works currently, leave it be. It's just personal preference. For many people, less symbols is simpler, and xml:lang="en_US" is more complex than <en_US></en_US>

Well, the problem is that it doesn't work... The issues I have taken up ar mostly not prsonal preferences but real problems. The standard doesn't deal with multiple "standalone" tags etc.
BTW, I have already begun. Too late

I have a bit of experience with XML parsers - not proper ones, though.

The lib uses TinyXML for the RAW parsing
I'm talking about the function that uses another XML lib to open a XML file

You call it "fine control" - I call it "simpler". It's very easy to see how it works, while your suggestion is slightly more subjective, and means more work for the developer.

Simpler? An APNG file is as simple as it can get. Then you only have to create 1 file and done.

My motto - KISS! Less symbols, less stuff that requires documentation. The final xml document should have visual patterns in it that make it easy to read and figure out.

But again, that's just my opinion.

If you add animation support, EVERY SINGLE pandora menu out there MUST support animation (no, it can't be included in lib_pnd)

Just my responses/0.02€

 

[lulzfish]

I was thinking the program would load the number of pictures, the prefix ["pic"] and suffix [".png", and then assume that the previews are going to be "prefix0suffix", "prefix1suffix" ... "prefix10suffix" where the program generates the numbers without any leading zeros, and the pictures are expected to be labelled as such.

edit: pic001.png and pic01.png wouldn't be valid filenames. The program won't be analyzing the available files, it will be expecting the files to be in a certain location based on their number.

"If you add animation support, EVERY SINGLE pandora menu out there MUST support animation"

Well if they want to be used, I guess. :/

more edit: I like APNGs personally, but there seems to be a lack of tools for creating them.
The good thing about APNGs is that they're valid PNGs too, so an APNG preview will run in any PNG-compatible menu, and APNG menus can still read the whole thing.

Anyway, the only way I could find to make one [<--- for my avatar] was to use a Firefox extension. GIMP wouldn't even export one.
So I think the series of discrete PNGs would be a lot easier to make, at least, if not to support.

 

[dflemstr]

To force filenames is a Bad Idea®. Users should have freedom (another reason why PXML should use XML)

Anyways, more discussion belongs somewhere else... Go to General!

 

[lulzfish]

Force filenames?
General?
We should start a discussion about this in General?

Sorry, I didn't understand your post.

 

[dflemstr]

Sorry, tired, will log out now XD
Yes, I ment that we should continue talking about this somewhere else Xd
And force filenames: You said that files should be named something like "prefix#suffix", which forces a number into there. I like Kramy's solution better because of that.

 

[lulzfish]

CODE
// Flip pictures every 6 seconds.
<preview repeat="yes" time="6000">
<pic>Pic_01.png</pic>
<pic>Pic_02.png</pic>
<pic>Pic_03.png</pic>
</preview>


Good point. What do you think about the timing setup? Something with just a list of pictures would probably be easiest to implement, but everyone would have to settle for something identical like "1 frame per second"
I guess I can't really say anything since I'm not the one developing this. :rolleyes:

 

[reyawn]

Interesting. I remember reading into the PXML format a long while ago and I kinda forgot about it until now.



I know that Skeezix does feel a certain pride in the lib_pnd library for interfacing with PXML files - however, I also know that making the file format 100% XML compatible will make the files more versatile and at the same time it would be easy to adapt the current library for accessibility. Why deliberately tie your hand behind your back?

I could see it being useful to make it compatible for a web tool - it would be great to use an XML parser to interface with the files online, perhaps if you were designing an online build tool.

Either way, now is certainly the ideal time to do something like this, before the hardware goes out to the masses!