Menu
▾
▴
RE: [Cdk-devel] CDK experiences and suggestions
|
From: Anatoli K. <ana...@in...> - 2003-09-25 10:35:54
|
Hello Egon, I am working with 20030909 build updated from CVS last week. I will double-check the issues you flagged as probably fixed. > Yes, JCP as a query tool is much needed. But help is required > here... I don't have experience with SMARTS. I will be happy to assist with SMARTS formatting if you need help. If you want I could submit a short requirements describing the basic entry-level query functionality and its specific applications to SMARTS. The good news is that nobody expects JCP to support full query definitions. Nevertheless, a relatively small flexibility in atom/bond definition could make it a remarkably useful query entry tool with limited number of effort. Cheers, Toly -----Original Message----- From: E.L. Willighagen [mailto:eg...@sc...] Sent: 25 September 2003 08:48 To: ana...@in...; cdk...@li... Subject: Re: [Cdk-devel] CDK experiences and suggestions A brief response: First, thanx for this valuable feedback. On Wednesday 24 September 2003 19:29, Anatoli Krassavine wrote: > Below is a brief list of our experiences of using CDK inside > our products. I will break them into appropriate bug reports, > RFEs and (even) RFC, but I believe holding them in one place > will allow to see them in perspective. Acknoledged. > Inherently this lists reflects our preferences and the > direction our products are taking. Nevertheless, I believe > that most of them will benefit CDK at large. I double-checked > that I am not repeating any existing fixes/CRs in my comments. > If I do - please disregard, :-). Are you using CVS HEAD, or the latest download? > In no particular order: > > What I consider to be a general improvements > 1) PRIVATE, DEFAULT access rights as I described in my e-mails > yesterday - I do not want to go into more details here Agreed. Can you give a list of classes (or packages) which are too private? > 2) Make components of JChemPaint to be more useful as standalone > components and not mandatory a part of JChemPaint Swing > application. For example, I want an easy way to have a single > (not multi-window) editor panel for entering structures. Ack... that could be made optional... please file this as a RFE at the jchempaint website... > Configurable toolbars and menubars (for example, I want to be > be able to disable Load/Save file menu). These are... 1.9.7 and cvs HEAD at least. Have a look the how -Dgui=X is used... > What I believe to be bugs > 3) Atom symbol depiction colours. The colour should be consistent > between atom symbol itself, hydrogens, isotope information > and charge. Presently, the atom symbol is painted using > r2dm.getAtomColor(atom), but all other elements of > atom symbol are painted using default foreground colour. > A trivial fix inside Renderer2D.paintAtomSymbol() > should address it Acknoledged. IMO can be considered a bug... > 4) The toolkit should make no assumptions implicit or explicit > about its ability to access a particular resource on > local disk by relative or absolute file path. This is > dangerous if it is used as a component outside of standard > CDK applications. Such functionality should be provided as > convenience methods, but not relied on. The resource should > be either be accessed from classpath or class should have a > public API. > > Examples: > TemplateHandler.loadTemplates() assumes it could > open directory "data/templates" and provides no > public API to specify templates manually. This crashes > on my system which in turn crashes SMILES layout. I thought Christoph had fixed this... not sure. > 5) Aromatic bonds depiction in Renderer2D could be improved. > It has two problems presently. First of all, the representation > of greyish double lines is not standard and might confuse > first-time users. They are ok for editor, but not renderer. > More importantly, the grey lines are misaligned (the edges > criss-cross) in contrast to generally very neat Renderer2D > depictions. > > Proposals: provide an option to switch between depicting > such structures as grey lines (it is still useful > for editor) OR using circles OR explicitly resolve double > bonds (see (8)). Fix grey lines alignment, so that they > look good. Yes, that should be possible... file a RFE. > 6) Triple bond spacing > Is a bit on a large side. Ack. BTW, this might very well be configurable with the Renderer2DModel... If not, it should... > 7) Intelligent background fill for atoms. > Currently the background of atom symbols (and associated > paraphernalia like charges, isotopes, hydrogens) is filled > with background colour to make it stand out. Good effective > solution. The problem is that the area to be filled is > calculated as the minimum rectangle encompassing all > elements of atom depiction. If the atom contains lots of > extra small elements (superscripts and subscripts), then > the filled space is getting too big (it pads too much space > around atom). This in turn might conceal bonds. > Example: > > C-15NH2-C stacked vertically (i.e. N isotope 15) > > single vertical bonds are barely visible > > Solution: > Use individual rectangle for individual visual elements to > fill smaller areas in appropriate places. Yes, sorry that this had not been filed yet, but it is a known bug... > What I consider to be a useful suggestions or feature requests > > 8) Provide a library to automatically resolve single/double > bonds for rings which are known to be aromatic. This should > not be applied automatically, but instead be an option. > I.e., if I load a fused ring structure from SMILES > c1cccc(cccc2)c12, I want to force correct allocation > on double bonds on it. This is less useful for editor, > but more useful for renderer. Agreed, a RFE. > 9) provide JChemPaint with aromatic templates and ability to > reallocate double bonds when fusing them (see JME for example) Interesting one too, but please file this at the JCP website. > 10) provide JChemPaint with optional dialogs to produce > SMARTS and possibly ISIS queries. I.e. lists of atoms, > halogens, conditional bond types, etc. This will make > JChemPaint a very valuable tool in submitting chemical > queries to databases. You might take a look at JME > for a minimum functionality set required - relatively > few additions (compared to the amount of functionality > already present in JChemPaint) could go a very long way. Yes, JCP as a query tool is much needed. But help is required here... I don't have experience with SMARTS. Egon -- eg...@sc... PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 |