Release pnd_utils

[skeezix]

We fiddled with putting a lame little index on the appended stuff, but never came to fruit; ie: a table of contents. As is, the appended stuff is sort of cheesed .. adding a PXML, and then an icon. If you add somrething else, its difficult to know where the one ends and the other begins, without actually parsing that stuff and slowing things down a bit. PXML ends with a well defined /PXML> and then everything after is icon. But if we start saying .. is this a jpeg? a png? how does it end.. lets find the end, and if theres more, it must be ... a mimetype? an audio sample?

Theres a limit I think to how much you can pack on there. (and doing half-way changes to the pnd format now probably would just confuse people..)

The one idea we had years ago was to append (or pre-pend!) a table of contents block; I think we'd toyed with putting it first in the pnd, and thus the iso was at an offset (which mount can handle just fine), and then using the TOC to jump to the payload items. But it was clunky, and we didn't do that, so.. yeah. (we didn't have a lot of time, we had to design and move fast, back then, for various reasons.. otherwise we could've done a mroe robust solution.)

When we go to .next, we could always try some ambitious new .pnd format (and also keep traditional pnd compatibility of course..)

So, sticking it into the PXML seems a valid solution; making a standard inject/remove tool for devs to use is also valid, but probabyl would get abused or screwed up, so standardizing behaviour in libpnd using PXML seems the best overall .. and not too hard.

*shrug*

 

[hmc]

the quote you quoted is actually saying I'm leaning towards dumping all the XML into the PXML, and spitting it out;

Oh, sorry, I misunderstood your posting. What I quoted indeed says that.

However, your example didn't:

<mimetypes>
<mimetpye name="what its for" filename="foo.xml">
...
</mimetype>
...
</mimetypes>
 

That was what confused me. This suggested to me that you prefer a solution where the PXML refers to another XML insider the PND for mimetypes (foo.xml).

So let me summarize (just to check that I got it right now):

The new structure would be:

<associations>
<association ... />
<association .../>
</assocations>

<mimetypes>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'> (<---- IS THIS NEEDED?)
<mime-type type="application/notecase-plain">
<comment>NoteCase Pro document</comment>
<magic priority="80">
<match type="string" offset="1" value="!DOCTYPE NoteCase-File"/>
</magic>
<glob pattern="*.ncd"/>
</mime-type>
<mime-type type="application/notecase-enc">
<comment>NoteCase Pro encrypted document</comment>
<magic priority="80">
<match type="string" offset="0" value="NOTECASE"/>
</magic>
<glob pattern="*.nce"/>
</mime-type>
....
</mime-info> (/<---- IS THIS NEEDED?)
</mimetypes>
(is the <mime-info> tag needed here? If this is standard, and if it is needed, libpnd could maybe add this automatically when writing out the mime type xml file? What do you think?)

And yes, I'll test the method in advance and report (putting the mimetype xml into /usr/share/mime and updating the database, then trying, if associations using those mime types work).

Oh, does the version of libpnd in SZ 1.53 already support associtations at all? I though it doesn't. So can you give me access to the one that does, please?

Thanks!

Daniel

 

[skeezix]

What I meant with:


<mimefile name="what its for" filename="foo.xml">
  <mime-type type="....">

  ...

  </mime-type/>

</mimefile>

<mimefile>

...

.. is:

name -> purely for documentation sake, or logging; not likely used by anything

filename -> filename to spit out into /usr/share/mime/applications/ as; we coudl generate somethign based on unique-id, but strikes me the developer may have a preference. like:

  <mimetype name="Atari 2600 ROM file" filename="x-rom-atari2600.xml"> -- if the file ends up being called c-1234-56789.xml it doesn't really help anyone whose looking for it; but if we can call it x-rom-atari2600.xml, thats way better.

I'd say (my thoguht of the hour that if we're putting mimetype XML into the PXML, we should put it _as is_, literally. libpnd shoudl not be tring to massage it and transform it (inject some wrappers or the like.) "Magic" tends to lead to confusion for the developers. Let them just copy/paste their whole XML files into it, and leave it at tht.. libpnd can then just spiut out what it sees, verbatim, and call it a day. No hidden surprise magic.

Now, I've been crazy busy this week so not put thought into this; do we do it liek I just did here, with one mimertype per <mimefile> just to make it obvious, or do it instead like:

<mimefiles>

<mimefile name="blah" filename="x-blah.xml">

  <mime-info...

  <mime-type..

</mimefile>

...

</mimefile>

This woudl allow 0,1, or more than one mime-files to be spit out, and each mime-file to include whatever contents the guy blams in there.

jeff

 

[hmc]

ah, okay, now I got it!

Thanks for clarifying.

 

[skeezix]

Someone remind me in a few days so I don't forget I generally avoid shaking the boat during an RC round .. introducing new bugs is for alpha/beta of the next round

jeff

 

[hmc]

Okay, just updated my OS to 1.54RC from 1.53 using updater.

First, I wanted to try, which exact command to use for updating the MIME database.

Problem:

$ sudo update-mime-database -V /usr/share/mime/
Updating MIME database in /usr/share/mime/...

Directory '/usr/share/mime/packages' does not exist!
The fix was easy:

$ sudo mkdir /usr/share/mime/packages
Now update-mime-database works.

Then, following the instructions on

https://wiki.archlinux.org/index.php/Changing_filetype_association_via_MIME

I threw the notecase.xml MIME definition file into /usr/share/mime/packages and re-run update-mime-database.

However, querying the file type of NoteCase Pro files using

$ xdg-mime query filetype file.ncz
still returned a file type of application/octet-stream.

Also, the graphical file manager still says, that the file is an "executable".

So I must be missing something here.

Any idea, what the missing part could be?

FYI, the files I used are these ones:

notecase.xml: The file with the MIME type definitions to add

file.ncz: A simple NoteCase Pro data file. (need to rename it to be able to attach it here. Please rename to "file.ncz" after downloading!)

Thanks for any hint.

 

[hmc]

no ideas here? :-(

 

[ptitSeb]

However, querying the file type of NoteCase Pro files using


$ xdg-mime query filetype file.ncz


still returned a file type of application/octet-stream.


Also, the graphical file manager still says, that the file is an "executable".

 Are you sure the graphical feedback on file manager is based on mime? I think it's based on attribute of the file, not the type (and on a Fat32, everything is executable).

 

[hmc]

No I am not sure. But other file types, even on the FAT32 volume, are displayed with the correct type in the file manager, e.g. .tgz, .tar.bz2, .jpg (even with thumbnail icon, .txt...

So, if it's not based on MIME, it's at least based on the file name extensions in some way.

 

[skeezix]

Sorry, I've been super tied up lately; keep at it. if you can sort it out, saves us work down the road

 

[Swordfish II]

Is this the only way to associate file types?

It would be nice to select a torrent file and have it open transmission and load, or a video file to open panplayer2 and play, a doc with libre...etc