Reporter plugin doesn't draw in preview pane

I’ve been pulling out my hair about why my reporter plugin doesn’t draw in the preview pane. Until I went back to the last stable version. It works in 3.1.2, but the “preview” draw method is just not called anymore in the current cutting edge 3241.



This is an intentional change, as the drawing of a reporter is often not what the user wants to see in the preview. There is new API in 3.2 that allows plugins to opt in to performing custom drawing in the preview pane (see GlyphsReporterProtocol.h):

Sometimes I wish the strategy of Glyphs was to really try not to break things that used to work in previous versions, rather than changing the behaviour (of itself and the API) in the blink of an eye, apparently without much consideration for those who have put some effort into making tools that work well with the app. After occasionally reading what user post on this forum, I believe users and the makers of add-ons alike would appreciate more consistency. It’s usually possible to implement new features (or distinctions) without breaking the users’ existing techniques and tools.

Part of the issue is the long beta period of 3.2, which is unfortunate, but should soon come to a close. The idea of cutting-edge versions is to try new things, see how they fit with the existing features and users’s setups, finalize the changes and provide detailed infos about what changed as part of the new (non-cutting-edge) release.

In this case, the old behavior was breaking some users’s functionality of the Preview Panel in a way that needed to be fixed. But there should have been clearer communication at the time about this change, especially because the detailed changelog of 3.2 ended up taking too long.

I understand what Florian writes, but also would like to second Tim’s comment.

Have you thought about something like a newsletter (or similar) that we developers could subscribe to, which informs us about such changes (deprecations, new/improved APIs, …), what they might break and what the new fixes are?

That would highly improve all involved poeple’s time (maybe not yours though, admittedly). I often find myself getting bug reports, not immediately understanding why things broke, needing to search or ask, puzzling the pieces together and implementing the fix without being sure if it is sustainable.

Also, this newsletter could provide us with necessary infos earlier than when the beta’s are turning into stables, so that the plugins can already work once the stable G is released.

The changelog is not a sufficient device for that kind of dev-to-dev communication.

And maybe deprecating APIs (and constants) for a little time could also be an option, so that plugins can implement the new API and maybe keep the old one around for backwards compatibility.

That is a good idea. But often those changes are not intentional. So I wouldn’t know to notify people about it. But we certainly can try.

1 Like

That should already be the case; old methods are kept and proxy to the new methods. The Python wrapper also helps with that by adding a buffer before the Core API.

A dev-centric changelog that keeps up during the cutting-edge phase would be a good start.

1 Like

Oh yeah, I hear you there. Just throwing in some thoughts, I can imagine how it can be tricky to keep track of your changes. Also it would need a good infrastructure, so that it won’t be a burden for you. Some way to easily push a note to the pile. Maybe there are tools for that. (For example a certain commit keyword, that when parsing all commits, gets extracts the commit note …)