UI Frameworks in Modo: Native vs. PySide

Modo 801 (2014) brought PySide support via Custom Viewports, and since then there has been some back and forth about the merits of PySide vs those of Modo’s native framework. When creating a new plugin for Modo, in all likelihood you’ll quickly find yourself wondering how you should go about creating the UI for it.

There are two frameworks available for creating UIs in Modo:

  1. The native system, based on forms, commands, and configs.
  2. Custom Viewports, which allow the embedding of PySide UIs.

These frameworks are fundamentally different on several levels. Choose the right one for the job, based on the needs of your plugin. Here is a quick overview of the two frameworks…

 

The Native Framework

  • The native framework will ensure your plugin is fully integrated. It handles the look consistently, so that controls and widgets are drawn and updated like any other part of the Modo UI.
  • It also handles the “feel”, by automatically enabling special behaviors like clicking with a modifier key, ganging multiple controls, doing basic math conversions inside numeric fields, input remapping, scriptability, drag and drop, or updating a layout when a viewport is resized.
  • Leverages Modo’s Command system, and requires it, in fact. You’ll need to know how to create custom commands.
  • Leverages Modo’s Form system, which allows you to place your custom commands into a layout or menu.
  • Steep learning curve. Documentation is sparse, with answers scattered across wikis and forum posts.
  • May not offer controls or viewtypes necessary for a particular design. For example, it wasn’t until recently that Modo’s native framework exposed Treeviews to 3rd party developers. You may not find the control type you’re looking for, but existing options are sufficient for most cases.
  • Reduced chance of breaking with subsequent builds of Modo.
  • The native framework is preferred for publicly-released plugins. The Foundry’s rule of thumb is that if it can be done with the native framework, it probably should be.

 

The PySide Framework

  • Does not offer automatic integration into Modo where the look and feel are concerned. Barring explicit stylesheets, PySide UIs will inherit from Modo’s global style if it is defined for a particular widget. But invariably, you will need to tweak the stylesheet to define the look you’re going for.
  • Automatic “Modo-like” behaviors are non-existent. If you want to emulate, say, Modo’s click-drag behavior on the arrows of numeric fields, you will need to implement your own and code this behavior explicitly (example). If you wish to match Modo’s look and feel, you’ve got your work cut out for you.
  • Conversely, this also means that you can create new behaviors if you like.
  • You have access to the full range of widgets available in the Qt library.
  • The documentations for Qt and PySide are excellent, with a deep pool of shared knowledge.
  • Does not necessarily require you to write custom commands, unless you plan on making changes to your scene, in which case a custom command is required (in order to provide an undo context).
  • Does not use the Form system (the UI is hosted by a Custom Viewport instead).
  • Allows you to code your UI by hand, or generate it in QtDesigner.
  • As a 3rd party framework, there’s always the chance of something breaking with an update somewhere.

 

In short, it’s a trade-off. On the one hand (Native) you have perfect, automatic integration, but a much higher learning curve, and with sparse documentation. On the other hand (PySide) you have no automatic integration, but more creative options and plenty of solid documentation.

In my view, the central question is simply this: do I need my plugin to be fully integrated into Modo? If you’re aiming to distribute this publicly or commercially, odds are that you do. If you’re creating something for your own purposes or those of your studio, probably not.

 

Further Reading