Donnie Berkholz wrote:
On 17:05 Tue 20 Jan , Paul Emsley wrote:
Roger Rowlett wrote:
I will second noting the loss of arp_waters in CCP4 6.1. I know there
is a "find waters" option in Coot 0.5.2 under "Calculate...Other
modeling tools", and perhaps this is adequate, but it doesn't seem to
have as many options for fine-tuning as arp_waters did. Coot allows
for finding waters above a certain sigma value; arp_waters allowed
this option plus setting minimum and maximum hydrogen bonding
distances between heavy atoms.
May I be so bold as to point you to the documentation?
http://www.ysbl.york.ac.uk/~emsley/coot/doc/chapters/user-manual_5.html#SEC127
If you want to use a command line program, type findwaters on the
command line and it will give a short description of the parameters it
takes.
(It is also documented in section 9.1 of the manual.)
One of the major reasons our lab started using Coot instead of O is that
you didn't have to memorize or look up a million obscure functions to do
everything. It was in the Coot GUI.
When we're training new people, this helps immensely for the 99% of them
who have never used Linux or any type of command line before. If there
isn't a GUI for it, it effectively doesn't exist for them. I would enjoy
understanding what the philosophy of the Coot developers is on this
matter.
Donnie,
I will answer your email here (not ccp4bb). I hope that that is OK.
The Coot GUI has taken a long time to get to the state it currently is
in. It is certainly in much better now than it would have
been if we had not acted on user-feedback [1]. It is equally certain
that the GUI is not as clear and well-organised as it could be. We do
try to listen - if people complain about the GUI/interface [2] then it
is slated for re-working - we just need to hear enough complaints.
(We know that this is a crude and non-optimal mechanism to design the
GUI.) [3]
There is (of course) only a limited amount of time that we
(collectively) have to work on the code. There are choices to be
made. Do we add a variety of new features [4] or should we add GUI
access to hundreds of esoteric settings and parameters for people who
don't want to read the manual? Yes, there is merit in providing a GUI
for features to functions and parameters previously only available via
scripting [5,6] but it is often not the most valuable thing we can be
doing "right now". Each setting/parameter we have to decide: is this
useful for a typical user or is this just clutter/esoteric/expert-use-only?
Having said that, the feature mentioned was added in the early days of
Coot - and if it was done today those extra parameters could well be
brought to the GUI surface.
To recap, Coot's gui/interface is in the state it is, not because
that's we think it's great as it is but because there are more
important things to add or fix first. Or so we judge.
[1] maybe that's just the way it is with non-trival GUI applications -
the developers will never get it right on their own.
[2] the rule used to be: 2 independent complaints about a particular
feature meant it was probably broken.
[3] we like to think that we have at least _some_ taste in GUI design.
[4] fast feature recognition, sequence assignment, restraint
modifications, glycosylation and disulfide-bridge refinement,
Ramachandran refinement restraints, better SEGID usage, electrostatic
surfaces, stereo, add support for PDB format version 3, binary build
for Macintosh and Windows, slick interaction with Refmac, libcheck,
jligand and PISA and other CCP4 programs? "Yes! all of those - and
double-quick about it!"?
[5] recently a GUI to ligand overlaying and manual NCS ghost
transformation definition have been added.
[6] we are also aware that there is also the danger of swamping the
GUI with too many dialogs and boxes - making the important things you
need to find quickly more obscure and hidden.
