New in Glyphs 3.2: Multiple plugin types in a single bundle

Info
1

Starting with Glyphs 3.2, it is possible to place multiple plugins in a single .glyphsPlugin bundle. Thus far, a bundle could only contain a single type of plugin:

  • .glyphsReporter
  • .glyphsFilter
  • .glyphsPalette
  • .glyphsFileFormat
  • .glyphsTool
  • .glyphsPlugin

Now, this differentiation is no longer needed. A .glyphsPlugin bundle can contain one or more plugin classes.

Single Plugin Class

If your bundle contains just a single plugin, as is commonly the case, you can continue to list the class of that plugin in the Info.plist file of the bundle as before:

<key>NSPrincipalClass</key>
<string>ExamplePluginClass</string>

Multiple Plugin Classes

New in Glyphs 3.2 is the ability to list multiple classes. For that, use the new Principal Classes key, like so:

<key>Principal Classes</key>
<array>
	<string>ExampleReporterClass</string>
	<string>ExamplePaletteClass</string>
</array>

In this case, the NSPrincipalClass key-value pair is ignored.

Instead of one of the more specific bundle file extensions, use .glyphsPlugin when your bundle contains multiple plugins. In general, .glyphsPlugin can be used by any bundle, whether it contains a single plugin or multiple plugins.

Use Cases for Multiple Plugin Classes in a Single Bundle

Combining multiple plugins into a single bundle is great for when your plugin makes use of different Glyphs features at the same time: A custom section in the Palette, a custom tool in the toolbar, a custom reporter in the View menu, or maybe even a custom file format. If you have such plugins that depend on each other, then they can now be installed with a single click in the Plugin Manager as one bundle.

The other benefit is that, since multiple plugins can live in the same bundle, they can also share the same utility classes, helper functions, constants, resources, and so on – no need to duplicate these assets across multiple bundles.

1 Like
2

:sparkles: This is amazing! Thanks for implementing this. :sparkles:

Will there be some changes to the Objective-C templates? Or if not, anything one would need to change in order to get it working in Xcode? No rush for this question, just curious while having read this news. Have no particular use case in mind atm.

3

You just need to edit the Info.plist file as described above. Depending on how your project is set up, there should be such a file in your resources or it is currently generated by Xcode, in which case you can add additional Info.plist keys. One way of doing so is by adding a “Info.plist File” value in the Packaging build settings of your target which points to a .plist file you add manually to the project. That file then just needs to contain the additional key-value pairs, like so:

Project settings:

1600Ă—476 53.2 KB

Custom Info.plist file:

1216Ă—298 30.2 KB

The Info.plist in the archived bundle should look something like this:

I personally don’t like to use the Xcode templates because, when I start a new Xcode project, I want to use the latest recommended build settings and project layout that Xcode gives me. So I just create a new bundle and then configure the plugin manually. I think that could be worthwhile documenting in written form. For now, I have a video where I do just that, with the key information in the video description:

1 Like