Update install.sh to support .pdez and .pdex on Linux

[processing-bot]

Created by: benfry

With 9a94ccf and related commits, a zip file with extension .pdex can be loaded as a Library/Mode/Tool/Example set, and a zip file with the extension .pdez will load a sketch from a single file. (The sketch will be unpacked into a temporary file.)

On Linux, we need to update the install.sh scripts and the .xml files that define the file types to include these two new associations.

[processing-bot]

Created by: johhnry

Hi,

I am interested by this issue. Looking at the existing processing-pde.xml file, the new MIME types should look like this (without the translations):

<mime-type type="text/x-processing.pdex">
  <comment>Processing Contribution Bundle</comment>
  <sub-class-of type="application/zip"/>
  <glob pattern="*.pdex"/>
</mime-type>

<mime-type type="text/x-processing.pdez">
  <comment>Processing Sketch Bundle</comment>
  <sub-class-of type="application/zip"/>
  <glob pattern="*.pdez"/>
</mime-type>

I am not sure though about the mime-type suffix but looking at the examples on the Wikipedia page, it shows that it can be useful to differentiate types.

For the type subclass, it should be one of those types:

application/zip, application/octet-stream, application/x-zip-compressed, multipart/x-zip

but which one is more adapted?

I listed the following changes:

• Define the format of the MIME types, text/x-processing.pde, text/x-processing.pdex, text/x-processing.pdez? (which means renaming the current mime type)

• Add the types to both processing-pde.xml and processing.sharedmimeinfo. (What about the translations? Is it done by multiple people?)

• In install.sh add the default app for pdex and pdez formats:

  xdg-mime default ${RESOURCE_NAME}.desktop text/x-processing
  xdg-mime default ${RESOURCE_NAME}.desktop text/x-processing.pdex
  xdg-mime default ${RESOURCE_NAME}.desktop text/x-processing.pdez

  Also install the corresponding icons using xdg-icon-resource install ...

What do you think?

[processing-bot]

Created by: jeremydouglass

Re:

For the type subclass, it should be one of those types:

application/zip, application/octet-stream, application/x-zip-compressed, multipart/x-zip

but which one is more adapted?

Probably use application/zip.

It isn't multipart -- that problem space (html form data submission and part splitting with a size header) isn't relevant to .pdex / .pdez. It isn't application/x-zip-compressed -- that says "this is compressed -- but that isn't necessarily true, if people are allowed to zip and unzip their own .pdex / .pdez directories, as zip can also package with no compression at all ( --compression-method store ) -- so no opinion on whether it is compressed or not. In fact, it is quite common to have containers like this intentionally not compressed so that applications can more easily access their contents directly without unpacking.

octet-stream just means "binary stuff". Most workflows that find this and still want to know how to handle it will then fall back to the type / file extension, .pdex, which they may not recognize if for example there isn't a handler pointing to PDE. So if you want minimal good behavior -- like the ability to inspect or unpack a zip packaged library or sketch with macOS Finder or Windows Explorer -- or Konqueror or Nautilus -- then the MIME type fallback should say "this is a zip!" so that you can interact with it without having to first rename it to .zip.

So: Use application/zip.

It is also possible to submit your own IANA Media Type / MIME type -- some examples of custom zip containers with their own registered MIME type include .cbr, .cbz, and .epub. A submission looks like this:

https://www.iana.org/assignments/media-types/application/vnd.comicbook+zip

However, the ones I'm familiar with in "archival container formats" using zip with a custom extension tend to have large ecosystems of software that all use the same format -- and in this case we would be starting out with just PDE, I believe...?

[Stefterv]

Part of #888