I take it the idea is that a plugin script would, on being run with the --print-options flag, return to Avogadro a JSON object that contains the tabular data? Avogadro would display that data to the user when the command is clicked in a table, and the user would then select something from the table and press OK, and Avogadro would then run the plugin script while passing along to the plugin the details of what was selected?
I’d have thought the best way to pass the tabular data would be in JSON format as well, in columnar fashion, with all data be quoted as strings:
{
"table": {
"headers": [
"Number",
"Name",
"Description",
...,
],
"data": [
["1739327", "1739326", ...],
["CH2O", "[C2O2N3S4]+ 2", ...],
["Molecular Energy - Gaussian", "Geometry Optimization - XTB", ...],
...
]
},
...
}
(If strings prevent the data from being formatted satisfactorily then we’d maybe want to add a list of datatypes; passing the data as native JSON types seems like it’d be too at risk of being changed over a round trip due to the multiple casting events that’d occur?)
When it comes to views, I would have thought that the plugin doesn’t need to know anything about any views or specify any view to show, as the plugin can restrict the data by only passing a subset if it so chooses (i.e. it can run queries/filters in advance). So views can just be handled exclusively within Avogadro, no?
Then wouldn’t we ideally avoid having to pick a full-blown DSL for instructions on how to manipulate the data and instead just enable a few specific details to be passed back and forth? In terms of what a plugin might want to receive back from Avogadro after the user input has been obtained, right now I can only think that the plugin would want to know which rows have been selected. Conceivably, it might alternatively want the user to select specific cells. But if there’s no need for more than that, I’m thinking that things could be kept simple by implementing something like the following:
The plugin could request a response at the same time as passing the data to Avogadro, like so:
{
"table": {
...
},
"request": {
"selection": "row",
"multiple": true,
"columns": ["Number", "Date"]
},
...
}
The plugin would indicate with columns the combination of values needed to uniquely identify a row and therefore what it needs the selection specification to include (in case the data doesn’t have a unique ID-like column).
When Avogadro receives the above request it would allow the user to select whole rows at a time (in whatever fashion, I don’t know what you’re envisaging – highlighting? checkboxes?) and would then tell the plugin which rows were selected. This would be as a list of rows, probably including the column names again just to allow the plugin to sanity check that the order hasn’t changed if it wishes:
{
"response": {
"headers": ["Number", "Date"],
"rows": [
{
"data": ["1739326", "9/2/2025 14:55"],
"selected": []
},
{
"data": ["1739324", "9/2/2025 14:52"],
"selected": []
}
]
},
...
}
rows would always be an array but would naturally only ever contain a single item if multiple were set to false. If row selection were requested then selected would always just be an empty array and the plugin would just ignore it, but if cell selection were requested then selected would contain a list of the columns which had been selected on that row. For example, if for whatever reason the plugin had actually wanted to allow selection of specific cells, Avogadro might return to the plugin:
{
"response": {
"headers": ["Number", "Date"],
"rows": [
{
"data": ["1739326", "9/2/2025 14:55"],
"selected": ["Name"]
},
{
"data": ["1739324", "9/2/2025 14:52"],
"selected": ["Name", "Description"]
}
]
},
...
}
I think with a result returned in that format, a plugin could fairly easily adapt it to whichever DSL it wants in order to perform its own operations on the original data.
