Good question. Not 100% sure … “append” probably still triggers an indication that the atoms / bonds changed, which is why I was suggesting the separate “readProperties” key.
It looks like an empty dialog shows up even if there aren’t any options. Then the debug / error message shows up.
I’ll go fix that. The code to detect that use case clearly isn’t good enough.
Okay, so the “append” part doesn’t work because it handles atoms and bonds. This part adds support for “readProperties” which just copies properties, charges, basis set, vibrations, etc. and leaves everything else alone.
It doesn’t yet work for these use cases because the surfaces and vibrations extensions don’t pay attention to the molecule changes. I’ll take care of that tomorrow - have a few other things to do tonight.
Nice, great. 
Will readProperties replace the current set of properties with the new ones or just add the differences? I.e. would an extant set of vibrations be deleted by passing only orbitals?
At the moment, it replaces the properties. Safely merging properties is a bit trickier.
In the meantime, I can verify that your Frequencies and Orbitals script do work with the patch.
Would support for QLabels in the script interface specification via userOptions be possible? As the user is basically left to themselves to set up calculations other than the preset Optimize, Orbitals etc., and is required to provide the terminal command they want executed, I’d like to refer the user to the xtb docs from the "Run..." window. I have already got an xtb Help option in the menu, but wouldn’t hurt to have a hint exactly when the user is most likely to need it.
Maybe an alternative would be a QButton that can be set to run another command script like docs.py, which is what is run by clicking xtb Help but that seems unnecessarily complex.
By the way, passing a molden file with "readProperties": True doesn’t seem to remove previously calculated frequencies after all. They remain available in the interface and saving the molecule and opening the cjson shows both MOs and frequencies present. 
Yes. I fixed that before merging the PR.
Maybe? I mean, I can see the use case, although toolTips are also supported. I guess you’d want the text to span both rows of the form? Or more like:
instructions: Type a command for xtb .. see https://xtb-docs.readthedocs.io/ for more
I mean, from my perspective, you want to cover most use cases with separate scripts. It’s the 80/20 or 90/10 rule … most usage will be “optimize this,” “give me some quick orbitals,” and “show me the vibrations.” Maybe add in “can I see a quick MD run?”
Adding a generic “run” command is somewhat useful, but more likely for people who already know what they want to do.
One other possibility would be an editable combo menu (eg., "type": "stringList") that offers a few examples, but allows free-form text entry?
Yeah I get this, and you’re right that most people will never need the generic Run.... My main motivation was just to avoid people being hamstrung by the extent of my implementation, that they don’t have to wait for me to add explicit options for solvation before they can run a calculation with solvation, for example. This way they can always run whatever xtb can run, even if the output won’t be automatically displayed in Avogadro.
Equally, should the command line usage of xtb ever change, even if everything else breaks, free specification of the CLI command will always still work.
Oh nice, how? Doesn’t seem to be mentioned in the docs. Just with "toolTip": string? Does this work for all the widgets?
Hmm, maybe that could work. Though those sorts of fields tend to suffer from it not being at all obvious that the text can be edited even after selecting.
Inspired by this I thought I’d simply put the url in the text field label. It actually looks adequate (for now) but the link is neither clickable (hard to implement) nor selectable with the cursor so copy+paste is not possible.
Having thought about it more I actually think this would be very nice. It would be the easiest to implement on the Avogadro side as all the QButton needs is text and the name of a Python file to execute in the exact same way as when menu options are selected, no? While on the scripting side, it would really make a lot of interesting functionality possible.
Regardless, there is a menu option for xtb Help which I think is fairly obvious and opens the docs in the browser. So there is no immediate need for anything else, I’m just spitballing really.
I found another use case for a simple QLabel, by the way – it would be nice to alert the user to the fact that changes made in the plugin’s Configure... dialog won’t diffuse to the other dialogs like Run... or Conformers... until Avogadro restarts. The only other way to do that at the moment would be with a popup using the functionality provided by "message", but I would like to avoid an extra popup appearing every single time the user changes something.
Yes, I think it’s also this one by @arugula_jones Animation Jitter Freq. Modes · Issue #1445 · OpenChemistry/avogadrolibs · GitHub
Having looked at the log file there, I’m not sure it is. The problem is stemming from openbabel skipping too many lines if a line for Ramen activity is present (see GitHub issue). @arugula_jones’s log file doesn’t have a Ramen Activ line, so it parses correctly, and converting it with obabel gives a .cjson with the correct number of displacement floats for each vibration.
Okay, I fixed your bug: Fix parsing "Gaussian" vibration output from xtb program by ghutchis · Pull Request #2653 · openbabel/openbabel · GitHub
There’s a bunch of Open Babel work, and I don’t know when I’ll get to all of that.
I also fixed the other bug - the problem was that optimizations show a trajectory which wasn’t being cleared properly for the vibration animations.
This is amazing and I am very grateful for such a fast fix! The vibrations now look like they should
It seems now also the Raman activity is written to the cjson output. Unfortunately this looks to have a new bug: the Raman intensities are simply a direct copy of the IR intensities. They should all be zero for all the examples I uploaded. Can you reproduce this?
Since Raman output has been removed permanently from xtb due to its inaccuracy, the results will always be 0, so I’ll change the plugin code anyway to make sure the Raman intensities get removed from the .cjson before passing it back. It would be misleading to show the user all 0s when some of the frequencies are Raman-active.
Yeah, coding at night clearly leads to 
That’s fixed. As a bonus, actual Gaussian calculations for Raman should actually work now.
Not far off having the MD implementation done! Is there a reason the float fields created using "userOptions" are limited to a max value of 99.99? I need the temperature in K…
Here is an example of the output for acetone from a 1 ps MD simulation. The results should be viewable with the animation tool, right? Because it’s not working for me, either by passing back the results with the script or by directly loading the resulting cjson. Would you mind taking a quick look at it and seeing what the issue is?
result.cjson.txt (956.5 KB)
Did you set maximum (and minimum) for that field? There’s also suffix if you want to add “K” to the field.
The problem with your result file is that the 3dSets are arrays of strings:
"3dSets": [
[
"-5.83383888405905",
"0.08166487209162",
"0.01438853881845",
not
"3dSets": [
[
-5.83383888405905,
0.08166487209162,
0.01438853881845,
Not sure how you’re handling them, but should be an easy fix.
Obviously 
where was syntax highlighting when I needed it…
I set minimum for several float fields to make sure they are positive values but never maximum. It seems setting the maximum value to something higher lets it work. And yes, I had seen, the suffix thing works very nicely, thanks.
Okay, there’s now a “text” type for adding a text field. I’m wondering if QTextEdit is a better choice (e.g., it includes support for Markdown) … and just make the default non-editable.