Implementation of custom element assignment from file #281
Conversation
|
|
| } | ||
|
|
||
| QStringList CustomElements::menuPath(QAction*) const | ||
| { | ||
| return QStringList() << tr("&Build"); | ||
| return QStringList() << tr("&Build") << tr("Assign &Custom Elements..."); |
There was a problem hiding this comment.
I'm unsure on naming here. Generally I hear "topology" more - I'm not sure if one is more prevalent. What do you think?
| m_progressDialog->setWindowTitle(tr("Reading File")); | ||
| m_progressDialog->setLabelText( | ||
| tr("Opening file '%1'\nwith '%2'").arg(fileName).arg(ident)); | ||
| /// @todo Add API to abort file ops |
There was a problem hiding this comment.
Wouldn't you just connect the cancel signal with m_fileReadThread => quit() instead?
| .arg(m_molecule->atomCount()) | ||
| .arg(mol->atomCount())); | ||
| } else { | ||
| size_t n = m_molecule->atomCount(); |
There was a problem hiding this comment.
If you get a file, do you want to map bonds as well? For the molecular-based trajectories (even XYZ) this seems like a good idea.
Signed-off-by: Adarsh Balasubramanian <badarsh2@gmail.com>
badarsh2
force-pushed
the
custom-element
branch
from
056d3d2
to
45d7d55
Compare
Signed-off-by: Adarsh Balasubramanian <badarsh2@gmail.com>
Signed-off-by: Adarsh Balasubramanian <badarsh2@gmail.com>
badarsh2
changed the title
|
Made the above suggested changes. |
There was a problem hiding this comment.
This can't be merged, it takes the background file format from the app, and adds it to a plugin. This causes duplicate symbol error on linking the application, and if we want to move this from the application to the libraries it would be better form to put it in the appropriate library and use the same implementation from there.
|
I moved the background file format script and headers to a new library folder and tried using these headers in the app, but mainwindow.cpp doesn't seem to recognise the header path, so I guess I'm missing out on something. Anything I should ensure while moving the files to a separate plugin and using them in the app? |
|
They should be moved to qtgui, and would need the export macros adding as other classes do so that the symbols are exported. They would also need putting into the same namespace as the other classes, they don't need to be in an entirely new library. |
Signed-off-by: Adarsh Balasubramanian <badarsh2@gmail.com>
Signed-off-by: Adarsh Balasubramanian <badarsh2@gmail.com>
badarsh2
force-pushed
the
custom-element
branch
from
6ad6e5a
to
84f72b7
Compare
|
@cryos I've made the suggested changes, and the plugin now uses the relocated backgroundfileformat class. |
|
@cryos - can you re-review this so we can merge if it's ready? |
|
Ping @cryos |
This is one of the ideas that I had proposed earlier to account for the non-availability of element information in many of the trajectory formats. Particularly in situations where the number of atoms in the system is huge, it becomes impractical to use the CustomElementDialog tool. Hence, in addition to the custom element mapping tool in the build menu, I've included an additional option to import the element information from file. This creates a temporary molecule class instance for the file imported, and the element information is copied from this molecule to the molecule in question. For example, if a GROMACS trr trajectory has been read, one can use this option to import a .gro file (just like normal file import, which is done using Avogadro's readers or OpenBabel if available) and the details of the elements will be reflected in the trajectory molecule. (This does not explicitly create a CustomElementMap, I have just used the setAtomicNumber() function to achieve the aforementioned).