This patch is not yet applied. Firstly some formatting - the epydoc
type text should be 'str' rather than 'str (directory)', etc. An
empty line has been added at line 76 which should not be there. And
the last one is that function argument default values should not have
spaces around the = sign, i.e. 'directory = None' should be
'directory=None'.
For appending the time info being appended to the pipe name, this
removes flexibility from the code and is a bit counter intuitive for
the API. There are 2 better solutions for this. The first is that
the default is set to None, and if no argument is given then the
automatic pipe name with time is created. The second is that the
calling code generates the data pipe with time stamp. I see either
way as being acceptable. The reasoning here is simple - if someone
uses this code and asks for a the data to be located in a defined data
pipe, changing the name of their special pipe (which might already
contain data) would be bad. They will struggle to work out why their
data pipe is empty or not modified. We should never clobber the
names, data, etc. of the calling code.
I am aware that several patches are combined (e.g. the flag for opening
the grace plots). My problem is that I cannot commit them seperatly and
the diff command messes them up.
You are quite quickly learning the ways group software development, so
soon I will be able to call a vote for you to be a full committer.
This should solve the issue!
Second, I don't understand why users should use the same pipe, as this
is not possible with the automatic analyses. If so, we need another flag
that tells the script whether it has to create a new pipe or use an
existing. This needs also some redesign of the gui, whcih would fit to
version 2, which will be more flexible (multiple windows instead of
tabs...). What do you think?
The concept is actually a bit different. The key here is that
normally no data pipe is given - then we can have our time-stamped
rx_auto_* pipe name. But if the user uses this in a different way and
directly specifies a given pipe, then we should respect their request.
This is a standard concept in designing an API - don't mangle things
that belong to the caller. They might have a purpose for this pipe
that we cannot foretell. For example they might be using the entire
of relax as python package from within a different program such as
Sparky (http://www.cgl.ucsf.edu/home/sparky/) or CARA
(http://cara.nmr.ch), and would like direct access to the contents of
this data pipe after performing an automatic relax_fit analysis on
their internal peak lists. Adding the time stamp to the data pipe
they supply will mean that they loose access to the contents of their
data pipe. The GUI can just specify nothing and the time stamps are
used. As this problem is only currently an issue from the usage
perspective of the GUI, the GUI could add the timestamps itself.
An alternative design would be that the relax_fit auto-analysis
__init__() method does not have a 'pipe_name' argument but instead
returns the rx_auto_* time-stamped data pipe name. Then the caller
knows where the data they would like to access is. I strongly prefer
the first design though because this will allow for a new concept in
the auto-analyses. That is that a data pipe is sent in which already
contains data. In the case of dauvegne_protocol this would be all the
data used in model-free analysis. For relax_fit this could be the
pre-created spin containers. The usefulness for the GUI in the case
would be that we could add menu entries for individual user functions.
I.e. 'Read sequence data'. The GUI event then directly executes
generic_fns.sequence.read(). This special storage data pipe can then
be read to display the sequence info in a tree view. I think this
ability would be very useful for the next incarnation of the GUI.
Regards,
Edward
Re: [task #6847] The Bieri graphical user interface.