Hmm, OK. That would make the case for append being an available option for geometry changes, then.
But that actually makes the case for the different contracts stronger!
At the moment, append applies to everything, right? So if a command changes the geometry by adding stuff, and wants to do what you suggest – return just the new atoms to be added along with append: true – then Avogadro will keep all the now-invalid properties that were present before. A plugin can’t ask for geometry information to be appended and for the existing properties to be discarded.
Whereas for a menuTransformer it would be a given that all the properties will be discarded anyway, and therefore append would work as expected (because the returned data is being appended to a property-less CJSON).
In any case, adding any extra categories is not urgent, it can be done post-2.0, it’s only removing/splitting/editing existing ones that is now-or-never. And it seems like the decision is to keep the current ones as they are, correct?
A thought: if the scope of each type is to stay as-is, maybe in the plugin downloader it might be nice to put which sub-features each plugin supports (the support.* keys in the metadata TOML) in brackets e.g. the features column could look like: File Formats (read, write) or Electrostatic Models (charges, potentials) or Energy Models (energy, gradient).
Right, a plugin can’t ask for that because it’s the job of the code making sure that any edits properly invalidate properties, provide undo / redo, etc.
Sounds like you’re pushing for new names, which is fine.
I can definitely see a benefit to knowing file format support (e.g., read but not write, etc.) but the other two… they both work. If an energy model doesn’t provide gradients (very rare with autodiff now) it will still work, just with numeric gradients. Maybe it shows up in some way as part of the README pane.
I’m not there yet. I’ll start in on the TOML parsing soon.
Fair enough then. I don’t know how complicated it is or how much work is done on the C++ side to detect those sorts of things. I think one of the key questions regarding anything that Brock or I have suggested is whether having a more defined contract with a plugin makes things easier for the C++ implementation (because assumptions can be made and whole bits of logic can be skipped) or harder (because more categories have to be handled).
Not really. In principal if I split the different categories (e.g., commands) into separate classes, it could work. Otherwise it’s a bunch of if-then-else statements and checking the logic carefully.
I think my feeling is “let me just work through this new framework” and we can talk later if there are new types needed.
On that subject, I think we can now parse pyproject.toml files. (This is probably a few days to a week to work through the plan.)