Currently working on the documentation. Can I suggest that we settle on using either plugin or extension to refer to the add-ons for Avogadro, rather than using a mix of both?
On the discussion forum I don’t think it matters what they’re called, but consistency within the UI and the docs would help clarity and understanding for users I think.
So far as I can tell, you @ghutchis refer to them as “plugins” more often. And within the UI and docs it’s pretty much always “plugin” rather than “extension”. The big exception is the Extensions menu of course. So seems like plugin would be the term of choice. Thoughts?
I’ve generally referred to the Python scripts as “plugins.”
The C++ code refers to bits that add menu commands as “Extensions” (which is what we used in Avogadro 1).
I’ve generally stuck to that usage because I don’t want confusion as far as “things that are part of the Avogadro codebase” and “scripts you can download.”
But if there’s significant confusion … 
I don’t care too much about this wording.
Ok so you’d like to maintain that distinction? That’s fine by me. I hadn’t realized they were being used with specific meanings, my bad.
I wouldn’t say there is necessarily significant confusion currently (other than my own). But I wanted to know what I should be calling them in the docs, so that I don’t generate confusion by referring to the Python script infrastructure by different names in different places. 
So by that logic, I guess plugins are a subset of extensions, and everything a user can install themselves would be a plugin, basically.
Yes, exactly.
I’m not sure I want to draw attention to plugins being a subset of extension, because we do have different kinds of plugins:
- charges
- commands
- input generators
- energy calculators
- file formats
Wasn’t going to, don’t worry 