Recommendations for Building Extensions ↩
Here at RoboFont we are not too strict concerning user interface components. If you want to use a series of checkboxes to build an interactive piano keyboard, go for it. Just be aware that checkboxes were probably not designed with that application in mind.
Consider that the user interface components you can access from the
vanilla module are distributed by Apple along with some guidelines. If you want to move away from convention, we suggest you to do it consciously.
mojo vs. lib
We recommend using tools from the
mojo module rather than
# this has been deprecated: from lib.tools.defaults import getDefault # use this instead: from mojo.UI import getDefault
from mojo.pens import decomposePen
There are two main reasons for following this recommendation:
mojoediting functions follow the
fontPartsAPI, so they are easier to use for scripter. Differently, the tools in the
libmodule are more defcon-oriented, so they use another API with a different logic
libmodule is not a publicly documented API, so it could change over time without explicit warning
Move to Merz & Subscriber
We really encourage developers to move to
Subscriber. These new modules increase users experience quality and they make your tool easier to develop.
Be kind with user’s data
Don’t do funky things with user’s data! Before uploading extensions to Mechanic, the RoboFont team will check the extension for malicious operations and suggest improvements to the user experience.
Code style can be a controversial topic of debate (remember tabs vs spaces?) between programmers. There is no strict rule to follow, just be aware that there is well established Python Style Guide out there.