ghutchis

Here’s my proposal about a simple visibility syntax:

"Solvent": {
  "type": "stringList",
  "values": ["Water", "Acetonitrile", "Benzene", "..."],
  "visibleWhen": { "key": "Solvation Model", "notEquals": "None" }
},
"UV States": {
  "type": "integer",
  "enabledWhen": { "key": "Calculation Type", "in": ["TD-DFT", "EOM-CCSD"] }
}

• Two properties: visibleWhen, enabledWhen
• Operators: equals, notEquals, in, notIn, greaterThan, lessThan. (isChecked is just equals: true.)

I think that handles a large number of cases (e.g., hiding or disabling parts of an input generator)

You can still delete them. You just need to go to the edit menu (or cut). I’m on the fence about it personally - I like the delete shortcut, but a bunch of people would accidentally delete atoms, so adding a slight barrier is recommended in UI / UX guides.

The reason the “bot” on GitHub suggests posting here is that a lot of the “bug reports” are more “I can’t figure out how to do X” and that’s much easier to handle here than “this is a bug and needs to be fixed in a patch.” And of course this template mentions GitHub so that real bug reports do get posted as well.

It’s not strictly a “no AI policy” - it’s a “any AI output needs critical evaluation by humans.”

Please open a PR - I’m guessing it’s mostly in the CMake files?

Thanks for the suggestion and offer - I’m very curious to see how a WebAssembly port would work. I think I have two concerns as far as WebAssembly:

• it’ll need to be fairly modular because the underlying codebase is modular - and some plugins may not map well into a web view (e.g., auto-opt and some other features use threading)
• the current design (esp. the edit tool) assume mouse use and I’d guess a WebAssembly port will get interest in e.g. tablet use in which touch gestures are much less accurate

But the best way to know is to give it a try and see what breaks.

Can you tell me a bit more about integrating into your web application? What do you have in mind?

6. If the molecular structure changes, properties should be invalidated, e.g. #2168
7. No, it copies atoms, bonds, residues, formal charges but no properties.
8. IIRC we had a discussion about this before, and properties should be retained unless there are replacement values (the implementation is in core/molecule.cpp)
9. That’s not possible, because at the moment the code (interfacescript.cpp) gives precedence to readProperties

I mean, it’s always better (more precise) if you have the cjson representation to make any specific changes you want. The main point for append and readProperties is to make it easier for plugin authors to do various things.

It’s much easier to use append to implement various “Build” tools because you just add the atoms and bonds to the scene.

If you think something is unreliable, that sounds like a bug report. Granted, “append” is probably not what you want for xtb when it comes to optimizations. OTOH, for “build this nanotube and add it to the current system” it makes more sense.

No. It reads the supplied format directly. There’s no “converting to CJSON.” (unless you’re supplying something that requires Open Babel conversion which would just slow things down)

1. append indicates that the contents of the file (i.e., atoms and/or bonds) should be added to the current system.
   readProperties was something you requested. It indicates to read properties, spectra, orbitals, etc. and add them to the current system - ignoring atoms and bonds.
2. See above
3. I’m not sure how these would apply to any other plugin type.
4. I don’t know why they would apply to the metadata. I can think of many, many scenarios in which you’d want to notify Avogadro only after running. I’m not really sure how it benefits Avogadro or the plugin if you want to declare append or readProperties ahead of time. Avogadro still needs to read the output JSON.
5. It makes sense to me, but I’m the one who wrote the code (and a bunch of plugins that use append)

I guess I want to know what you found confusing and/or unreliable. They work for my use cases certainly.