> In general, I don't think the color schemes are that important, but CDK > uses the approach of having alternative color schemes... Miguel, I > would have to check how it is currently implemented in HEAD... but > would that be an alternative...?: > > set color scheme [jmol|rasmol|weblab] > > (in arbitrary command names)
A couple of different thoughts on this topic. * Adding additional 'fixed' tables would not be difficult. But it would take up additional space. Rather, I think I would lean towards implementing a table reader to support a user-defined table. * I don't think I would make an explicit 'jmol' scheme. Rather, I would vote in favor of adapting the rasmol scheme. As I see it, the biggest problem with the rasmol scheme is that it only defines the organic atoms. Therefore, all the inorganic ones could be adapted ... to either weblab or the current jmol color. * The JmolModelAdapter allows the client to implement its own color scheme. So the CDK Model Adapter could provide its own color information. It may not currently be doing this. You may recall that we had a lot of problems with this and were getting lots of pink atoms. Therefore, it may be turned off. * Additionally, the scripting language supports changing atom colors. > BTW, how does coloring it by charge relate to this? Color by charge is not yet implemented. However, I recently added a member to the Atom object in order to store charge information. That field is being used to support ionic radii. This same charge field can now be easily used to render color by charge. Miguel ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
