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

Activity

1. processing-bot commented on Aug 25, 2021

   

   processing-bot

   on Aug 25, 2021

   CollaboratorAuthor

   More actions

   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?
2. processing-bot commented on Aug 29, 2021

   

   processing-bot

   on Aug 29, 2021

   CollaboratorAuthor

   More actions

   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...?
3. Stefterv commented on Mar 11, 2025

   

   Stefterv

   on Mar 11, 2025

   Member

   More actions

   Part of #888
4. Stefterv

   closed this as completedon Mar 11, 2025