This pull request introduces 1 alert when merging 503d1f5 into db455c1 - view on LGTM.com

new alerts:

• 1 for Missing return statement

Here are some sample plugins, both source and installable archives (in dist):
play_plugins.zip

As the name suggests these aren't polished systems but quick adaptions of scripts I had lying around.

We need more information.

• Which plugins will be distributed by default?
• Which libraries are we guaranteeing to exist? Tkinter? Or is the plugin manifest supposed to specify Tkinter?
• Is there a UI for managing plugins?

There is a UI for configuring how the plugins installed on your own system interact with your instance of FontForge. You bring it up with a menu option under "File". That stuff is described in the documentation added in this PR.

Your other questions relate to the discussion/disagreement in #4062. Note that I'm not marking that issue as being closed by this. This is a mechanism that allows user-developers to more easily share their FontForge extensions with the user base. My suggestion that we address "the contrib question" with a meta-package is just that, the project needn't go that route.

There are a number of improvements to the Python API I plan to pursue in the gap between this being merged and the next release, whenever that is. (This is assuming I have the time to pursue them, of course.) I don't want to get into that "here" because they're not directly related; they would be just as much benefit to an "init script" developer as a plugin developer.

However, one is a limited means of specifying multi-parameter dialogs, similar to the "could we just use the Params dialog template?" idea that @ctrlcctrlv and I discussed a while back. It's a compromise that lets a user bring up a dialog with a lot of different options without a lot of control over how they're spatially presented. I think it will work for 90% of the cases and in a way that's far less likely to rot over time. This will be a bit of work: In addition to just the general UI foo (I think?) I'll need to build a wrapping layout manager analogous to GHVBoxCreate.

(Another improvement is adding an "Apply protocol" callback option to the ask-like dialogs, including the new one, so that you make them work like the current Transform dialog.)

Oh okay, I understand the scope of this change now. Tkinter can be provided as a requirements.txt entry, so I'm just noting that can happen with Pip installable packages.

If you consider contrib a separate problem, I agree, so we can put a pin in that for now :)

I'm thinking the best way for me to test this is to convert ctrlcctrlv/QuickAnchors into a pip package. Thoughts on that approach?

Thoughts on that approach?

There are somewhat separate questions of "Is this functionality worth adding?" (testing the idea) and "Does this do what it says it does without crashing?" (testing the code). The first question also closely relates to what documentation we should write and what further steps, if any, we should take with the python dev and user communities.

So what I would say is: That's absolutely a great idea relative to the first question and I strongly encourage it. If your plugin doesn't have or need preferences you might get by with just the techref/pyextend.rst document I've added (and attempting to just get by with it would tell us some ways it needs to be improved). I just looked at the existing script and it has the "typical" structure I describe in that doc.

(I don't yet say anything about dependencies, and the docs probably should. In many cases you might get away with just an install_requires directive in the setup.cfg file (under "[options]" and similar in format to "classifiers" in the "[metadata]" section). Whether you need a requirements.txt file seems to be a complicated question.)

If the plugin does have preferences or you want to add them, well, I should add something about the preferences callback anyway -- it's quite simple. (However, before there's more development work on the "ask' dialogs you might want to TkInter yourself a window for that.)

Anyway, this could take you as little as 15 minutes or so, if you just copy and adapt the current MidContour config into your https://github.com/ctrlcctrlv/QuickAnchors repo. (I would skip PyPI for now, both because it's more work and because people may get confused if they start seeing plugins listed before a released version of FontForge can support them.)

For breadth of testing, which I've already done some of, we can mix your plugin with some of the fake ones I uploaded and folks can play around with them. So: a benefit but not a solution.

Oh -- @jtanx I forgot a lingering issue in this code.

If you were to glance at pluginui.c:FigurePluginList() in this PR you'd notice:

    GList_Glib *p;


    for (i = 0, p = plugin_data; p != NULL; ++i, p = p->next) {
        PluginEntry *pe = (PluginEntry *) p->data;
        pe->new_mode = pe->startup_mode;
        ti[i] = calloc(1, sizeof(GTextInfo));
        ti[i]->text = pluginDescString(pe, &has_err);
        ti[i]->fg = ti[i]->bg = COLOR_DEFAULT;
        if (has_err) {
            ti[i]->fg = COLOR_CREATE(0xBD, 0x43, 0x37);
        }
        ti[i]->userdata = pe;
    }

One thing you may be happy about is that plugin_data is a GList_Glib pointer. One thing you may be less happy about is that hard-coded color.

I looked in our X Resources stuff and:

1. It doesn't look like there's a standard "error condition" color, nor is there a (gdraw) GList-specific error condition color.
2. It wasn't clear to me how I would go about adding one, given the depth and breadth of all that stuff.

Do you have any thoughts on this? Best practices? Implementation help? I can also just abandon the idea ...

Do you have any thoughts on this? Best practices? Implementation help? I can also just abandon the idea ...

Your guess is as good as mine to be honest. You could probably add the concept in if you spent enough time, but I'm not sure it's worth the effort. I'd be fine for hard-coding it for now, even if it is perhaps not the most ideal.

Which libraries are we guaranteeing to exist? Tkinter? Or is the plugin manifest supposed to specify Tkinter?

This is purely a packaging decision, like your Python distribution either comes installed with tkinter or it doesn't, you can't pip install it. I am OK with that, I don't think the plugin system should prescribe whether or not it's required. If your plugin depends on something and it isn't available, too bad (of course since these are basically just python packages, if they can install dependencies via pip then fine). We have control over the binaries we ship, and can choose to include or exclude whatever we like, but that doesn't prevent distros/users from doing what they like, and if they choose to install python without tkinter then so be it.

If your plugin depends on something and it isn't available, too bad

The only thing I would add to this is that it would probably be a good idea to define (or, more likely, pick) an exception type that, when returned from fontforge_plugin_init(), indicates that the plugin can't find a runtime that can't be handled via dependencies. Then I can give that a separate "Info String" to display in the dialog. I'll look into that.

@davelab6 It's not so much about the current amount of traffic as the potential burst in traffic and who may be subscribed. If folks signed up thinking the list was for direct contributions and not helping people with their plugins and sorting out the API then they could get annoyed. But it could also be fine, I don't really know.

I just checked the archives and traffic has been at such a low level that we can probably just send a note warning about the change in emphasis on fontforge-devel so people can unsubscribe if they want. Seems easiest.

tkinter can be added to setup.py install_requires like any other package , but if it isn't found it can't be installed without manual intervention, it won't be automatically pulled from pip because it's not pip-installable. Plenty of packages still put it in install_requires though.

This isn't really our problem because pip will refuse to install the package way before FontForge ever crashes on it, so it's more of a contrib issue than anything.

I added a warning for enabled plugins that aren't found and significantly expanded the documentation.

Back when I got subscription change notifications, we did indeed get a wave of cancellations whenever somebody hijacked the announcement list for a user or engineering issue. I imagine that the same holds true for the user list. If something is beyond the understanding or interest of a casual user, I think that we need to keep it on the engineering list.

@frank-trampe: So maybe one announcement on fontforge-users noting that there's going to be a phase of discussion about contributed features on fontforge-dev. One warning on fontforge-dev in case anyone wants to unsubscribe in the fact of increased traffic?

That sounds generally right to me, although I'm inclined to push as much of the substantive engineering discussion to the issue tracker. I propose the following. The users list gets a notification that we are working on a new plug-in interface, with discussion happening here. The engineering list gets the same notification with the additional note that discussion of new plug-ins may happen on the engineering list and that we will announce significant plug-ins (likely in conjunction with mainstream releases) on the announcement list.

Was just playing around with this on Windows - had a couple of questions/notes

• What's the point of the delete button if all it does is disable the plugin?
• When you press delete then cancel, the state changes (the plugin becomes disabled), but I would have expected it to cancel the action and do nothing. Similarly it moves it to the bottom of the list(?)
• What does it mean to load a plugin without enabling it? Is this like a once-off load for this session that isn't persisted?
• Not that big of a deal, but there's no way to select multiple to enable/disable
• There are a lot of options presented on the plugin window - a little overwhelming to be honest.
• When I click enable for a plugin, I would expect it to be loaded immediately

What's the point of the delete button if all it does is disable the plugin?

Delete is primarily for removing the entry of a plugin that is no longer installed. I suppose I could just enable it in that case -- there's no particular reason a user should be able to put an entry back in "new/ask" mode.

When you press delete then cancel, the state changes (the plugin becomes disabled), but I would have expected it to cancel the action and do nothing. Similarly it moves it to the bottom of the list(?)

I'll look at that.

What does it mean to load a plugin without enabling it? Is this like a once-off load for this session that isn't persisted?

Yes.

Not that big of a deal, but there's no way to select multiple to enable/disable

Yeah, I'm probably not going to get into that for this release.

There are a lot of options presented on the plugin window - a little overwhelming to be honest.

It's the usual problem that 80% of the stuff will only be wanted by 20% of the users, but the latter will want those things.

When I click enable for a plugin, I would expect it to be loaded immediately

I'll think about that. People who don't care about ordering will expect that. People who do care about ordering might not.

I updated the code so that only an undiscovered plugin can be deleted.

I also now offer (in a button choice dialog) to load a plugin that is newly enabled.

When you press delete then cancel, the state changes (the plugin becomes disabled), but I would have expected it to cancel the action and do nothing. Similarly it moves it to the bottom of the list(?)

This is likely no longer relevant but I'm not sure how it would have been happening. If you still see something along these lines please describe a repeatable test case.

This is likely no longer relevant but I'm not sure how it would have been happening. If you still see something along these lines please describe a repeatable test case.

Since you removed the ability to 'Delete' a discoverable plugin (so you can't cancel the action) it's no longer possible.

What are your views on init scripts going forward? Keep it? Deprecate it? Let me know if I'm missing anything, but I see it as the functionality being basically the same as an init script except you add on better discoverability(assuming people follow the conventions when uploading to pypi)+version management and that you've added a mechanism to load them from system python.

If someone is just making a little extension for themselves and doesn't want to get into Python packaging an init script still seems like a fine mechanism. It's a bit unfortunately hidden at this point -- the location where they need to be isn't documented very well/accurately. But I still expect future plugins will start their lives as init scripts.

I guess my view is that init scripts will continue to be for "personal use" and plugins will be for when someone generalizes a feature enough to make it worth sharing. The biggest advantage of plugins is PyPI and, once things get going, the https://pypi.org/search/?q=%22FontForge_plugin%22 link. Rather than building its own database, distribution, and installation system the FontForge project can just use Python's. That's the main thing this buys.

Any remaining thoughts before this is merged? @frank-trampe?

This would be my initial guidance on "communication", which it might be better to delay kicking off until #4671 and maybe the registerMenuItem() improvements are merged:

1. We announce to fontforge-users that the upcoming release will have a number of UI extension improvements and a Python plugin system, so that extensions can be bundled and installed as normal Python packages (searchable on PyPI, installable with pip). Anyone who may be interested in extension development should subscribe to fontforge-dev.
2. A bit later we announce to fontforge-dev that there may be increased traffic due to discussion of the new extension features. We stress that we very much want to get the solutions sitting in individual init scripts more generally available. Then we encourage the following:
   • Interested users should consult the new technical documentation and probably an FAQ on the Wiki where we can provide important answers.
   • Users with difficult/specific questions are encouraged to look through the relevant categories at https://github.com/fontforge/fontforge/discussions to see if their question is answered, and if not open a new discussion.
   • Users with more general "how do I do blah" questions can feel free to ask on fontforge-dev (That's what it's for, I think?)
   • Users who make a plugin that may be of interest should contact us (how? email?) so that we can mention it on fontforge-announce.

I don't have discussion category edit privileges. Can someone maybe do https://docs.github.com/en/discussions/managing-discussions-for-your-community/managing-categories-for-discussions-in-your-repository#creating-a-category to add "Plugin Q&A" and "Plugin Show and Tell" categories?

Alright, if there are no updates before Thursday evening I'll merge this.

@skef, This sounds really exciting. Thanks for all your amazing work on this and all the recent improved python support. I don't think I'm the only one who will welcome some improvements in the plugin realm.

I feel quite like a dunce, though, not able to understand how I can use this on Windows or how it differs from "the old way" of creating plugins/scripts. Do you (or someone) plan on putting together a step-by-step tutorial (with pictures, preferably)? That would help me tremendously and I think would spur more plugin development from the userbase.

The windows version of FontForge (at least the one that we compile) has a built-in python interpreter separate from the system one (assuming one is installed). But I believe it bundles pip, which can be used to install PyPI packages.

As far as plugin development goes, the plugin interface itself doesn't make that much different. The multiask dialog and the improved menu support (assuming that gets merged) do improve the options. The plugin idea is more about user discovery and distribution. Sharing FontForge scripts never really took off, partly because there was no master list and "installing" them can be confusing. Now people will be able to search on a keyword in PyPI and install additional FontForge functionality using the python package ecosystem.

We will probably set up a "blank plugin" repository as a starting point for interested developers at some point (@jtanx's suggestion).

I see now. Thanks for the additional explanation.

I have developed quite a library of functions I use regularly through the plugin framework. This could entice me to break out what I've done into separate, shareable plugins. I'd certainly be interested to know if there are many others who have successfully gotten their own plugins to work to enhance FF's functionality because it can be very frustrating at times. It's been a huge blessing for me, though, to have the ones I've created.

@tisimst I doubt there are many, because this isn't in a release yet, but there is also me. If you meant, “have many people managed to do all sorts of things via FontForge Python API (before it included pip-packaged plugins)?" the answer is certainly yes.

Well, I created all of my plugins well before this functionality manifested. I think you're probably right, though, that there aren't a lot of people who've taken the plunge and gotten very far before throwing their hands up in frustration. I certainly almost did, but was able to develop a few very much needed helper functions that could adequately tell me when I was doing something wrong.

Anyway, still, if the ability to pass plugins along via pip works well, I'd consider figuring out how to package mine to share with others.