at 10.06a EDT on 2004 January 14 Wednesday Miguel Howard said: > > 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. > me too.
> * 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 agree this would be best, with the Jmol default being the CPK scheme. I don't think the exact variations are crucial. IOW, whether carbon is full black, dark gray, or light gray is not a huge issue, especially if the user can save their preferred variations. so I would go with exact variations that look best on screen. > * 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. > I would argue against defining color schemes based on other software. for example, WebLab does not exist any more - it is called DSViewer and has changed ownership several times. also, if other software changes color schemes, Jmol will have to follow suit to maintain consistency. if CPK is implemented, and user colors as well, I think that will provide a comfortable level of compatibility with RasMol and Chime, and familiarity for all (or most) users. > * 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. > I don't recall if any other well-known mol vis programs color by charge; I'll check it out. as a developer, I usually use lightened shades of blue (positive) and red (negative) to indicate charge. regards, :tim -- timothy driscoll molvisions - molecular graphics & visualization <http://www.molvisions.com/> usa:north carolina:wake forest ------------------------------------------------------- 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
