Hi,
Please see below.
2010/1/18 Michael Bieri <michael.bieri@xxxxxx>:
Hi Edward
Thank you for your hard work.
No problems :) I will try to make sure your code gets in to make the
GUI as powerful and as useful as possible. This will increase the
citation count!
2) Import fixes. All 'from xxx import *' statements need to be
eliminated.
removed
This needs to be in a single patch.
3) Commenting. There is to much code with not explanation as to what
it is doing. To understand the current code base, you need to
understand what all the wx calls do and also know exactly how the GUI
is designed a priori. You should be able to read the code and
especially the comments, and picture in your head what the GUI looks
like. I would suggest splitting the GUI code up a little more into
many little methods for each GUI element. My skills in Python coding
now after 10 years of practice are pretty good, but to me the code in
__init__(), __set_properties(), __do_layout() reads like
hieroglyphics. __do_layout() has 725 lines of code without any
spacing or any comments! Use comments to explain what you are doing,
and spacing to format and isolate logical blocks.
I'd like to postpone this until we finished a working version that can
be published. But I will do this!
Ok, but note that this has a huge crippling effect on how much I, or
others, can help. It also helps massively with debugging.
4) Object oriented design. The global variables should not be in the
namespace of the gui_bieri.relax_gui module, but rather in the 'main'
class which was initialised as 'relaxGUI_main'. They could be
packaged together using data containers (empty class instances), and
placed in the main class. The global variables are debugging hell, as
they are accessed from the functions imported from other modules. The
class namespace is the proper place to put these things. Note that
point 7) below will eliminate these anyway.
??? that's a bit too hight for me. Are you suggesting to put the global
variables in the main class? I don't understand the container thing... sorry
I can do this part. These suggestions are not all for you to do, but
things that should be done to make the GUI better for users. And I
will help you code. You create variables by typing, for example:
# CSA for all spins.
ds.relax_gui.global_setting[1] = -160e-6
or maybe:
ds.relax_gui.csa = -160e-6
This is very simple. You have a box, ds.relax_gui, and everything
goes into it. I.e. no modifiable variables go into the module
namespaces.
5) Exiting. If the user asks the program to exit, the program
shouldn't then ask the user to exit the program. Maybe to avoid
issues, a dirty flag can be added to the main class which is changed
to True as soon as the user changes the program state. Then the
question at the end can be 'Are you sure you would like to exit
without saving?', but only if the dirty flag is set.
We can include this. Anyway, I removed the close box on the window to
avoid leaving the program unsaved.
I think the pain it causes outweighs the benefit. I would like to
introduce the dirty flag though, despite the difficulties. I would
defer it until later though, and it can be done bit by bit.
6) Break the dependence between the model-free analysis and the Rx
and NOE calculations. See point 8) about flexibility for solutions.
The point here is that someone might come along with the R1, R2, and
NOE data pre-calculated.
users are able to independently add parameter files. The only thing that
is missing is a settings panel, where the user defines the location of
data and sequence column. That's one of the next mandatory steps. (The
naming >Settings>Parameter File should anyway replaced with Peak File)
Ah, ok. This is in the setup where you input the NOE, R1, and R2 as
files. I wasn't seeing this before because of a bug. Try the
following with r10241 of the branch. Click on 'Settings -> Parameter
File Settings', then try in the 'Model-free' tab clicking on the '+'
button for the NOE of the first frequency. I get the error:
Traceback (most recent call last):
File "/media/disk/relax/branches/bieri_gui/gui_bieri/relax_gui.py",
line 2047, in param_file_setting
if question('Do you realy want to change import file settings?'):
File "/media/disk/relax/branches/bieri_gui/gui_bieri/res/message.py",
line 89, in question
startrelax = wx.MessageDialog(None, message = msg, style =
wx.YES_NO | wx.NO_DEFAULT)
File
"/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_windows.py",
line 2909, in __init__
_windows_.MessageDialog_swiginit(self,_windows_.new_MessageDialog(*args,
**kwargs))
wx._core.PyNoAppError: The wx.App object must be created first!
I'm guessing this is because the parameter file settings section is
not complete.
7) Integration with the relax data store. Much of the data stored
globally can be made more permanent by placing them in the relax data
store. For example the user types out all the info required for
loading relaxation data into a model-free data analysis. There could
then be a 'store' button at the bottom which will commit this
information to the relax data store by calling
generic_fns.relax_data.read(). All the fields should correspond to
all arguments of the relax_data.read() user function and allow all
possibilities accepted by this function. Then the given relaxation
data set should appear in a list to the side. Maybe the user can
click on this list to select data sets to delete or modify. But after
clicking on 'store', all fields then go blank. Similar things can
occur for all user input. The relax data store is where all this info
can go, and is what is saved by the state.save() user function. 'File
-> Save as' and 'File -> Save' should call generic_fns.state.save() as
well. For loading, the generic_fns.state.load() function can be used.
Then the GUI pulls out of the store all the information required to
restore the GUI. If there is information about GUI layout that needs
to be saved, this should be stored in the relax data store. This is a
singleton, so you can use:
from data import Relax_data_store; ds = Relax_data_store()
I would suggest adding GUI properties into a data.data_classes.Element
class element so that it is properly saved (I might need to improve
the data container for this). I.e. you would have code along the
lines of:
For importing:
from data.data_classes import Element
For initialisation:
ds.relax_gui = Element()
For storing settings:
ds.relax_gui.my_setting = self.my_setting
Initialisation can be performed when launching the GUI. Storing can
occur when the setting changes. For the automatic modes described in
8), an Element instance could be used to store the data of each
analysis separately. In any case, all permanent data storage should
be within the data store and not globally or within the 'main' GUI
class.
I would also like to postpone this issue until we have a publishable
version.
This is again something I can work on (with your help in the form of
explanations).
8) Flexibility. This is a big one that will require a lot of
redesign. The scripting and prompt interface of relax is currently
quite flexible. The GUI though is not so. For example say I would
like to analyse RNA and have 15N and 13C data for about ~8 spins per
residue. And this data is the R1, R2, and NOE at 900, and the R1, and
R2 at 600. This will currently fail. The same with small molecules.
What if I would like to set the bond length of a set of spins to be
longer than that of the others? Or have a per-spin CSA value, if
these have been measured using other means? Or if I have collected
data at 6 field strengths? Some of these issues are problems with the
current 'full_analysis.py' script, but we should still design with the
flexibility in mind and maybe make the GUI even more powerful than
this sample script. I would suggest to design the GUI around the
current user functions and data pipe types.
I agree, but also postpone??
For some parts yes, for others something has to be done. Minimally
you have to explain to the user what is going on! The major problem
is if the user tries out the interface and finds it too limiting.
They will automatically switch to the scripting interface, and that is
a lost citation. Some flexibility at the start will go a long way.
a) Data analyses. I would suggest starting the GUI with a blank
canvas. Then there would be a menu entry to add a new data analysis
(maybe part of a row of buttons just under the menu bar). This would
bring up a window with a list of all the data analyses supported by
relax. Maybe clicking on each could bring up the icon of it and a
description. Once selected and the button 'Initialise' is clicked,
then the canvas is set up for that analysis type.
Which options would you suggest? we could set a parent window as you
said and then open child dialogs/windows such as the main window of the
current version.
I would suggest maybe a window with 5 or 6 buttons. These include
noe.gif, r1.png, r2.png, and modelfree.png, and an empty grey box.
These will have the text "NOE calculation", "R1 fitting", "R2
fitting", "Model-free analysis", and "Custom analysis". The custom
analysis will be greyed out though, with maybe some text that appears
on focus saying something like "Not implemented yet, please use the
prompt or scripting interface instead". At the top there would be
text such as "Please select from one of the following preset
analyses:". Then there would be a menu entry "File -> New analysis"
to add the other tabs. This involves a bit of work, but would
significantly help the user.
b) 'Automatic' vs. 'custom' modes. Currently the GUI forces the user
to perform the analysis in a preset way. In the dialog of 8a, maybe
the user would have the option of selecting between automatic and
custom modes. These would then set up the canvas in a different way.
I would suggest having both, but making the 'custom' mode grey with
text saying 'not implemented yet' appearing upon mouse focus. The
custom interface could in the end be the 3D Open GL canvas ideas I put
forth many years ago when redesigning relax
(https://mail.gna.org/public/relax-devel/2006-10/msg00053.html),
specifically at the end of section 2.3
(https://mail.gna.org/public/relax-devel/2006-10/msg00056.html). Or
maybe one of the analysis types could be called 'blank canvas' which
would then open up this 3D canvas and a series of buttons for all the
user functions. In any case, it should be explained to the user what
these modes entail. I. e. it is an automatic mode that hides the full
flexibility of relax.
I would prefer to add some settings dialogs, where users can change all
values (grouped). But by starting or opening relaxGUI, predefined values
are given. These values can be saved and restored, if the user changes
some of these.
Here I am talking about the tabs on the left hand side rather than the
user modifiable values. I.e. the UI elements are not pre-created when
the program is launched, but rather when the user requires them.
Think of adding a new tab in excel. Or a new tab in firefox. The
same analysis selection dialog could be used to select the analysis
type.
c) The automatic protocols. Initialising each one will then bring up
a new canvas giving a summary of the setup. These could be laid out
in tabs (like the current row on the left, just with each been added
one after the other). I would suggest the tabs be buttons with icons
if on the left. Otherwise it might be better to have the tabs at the
top? Or at the bottom? I might be nice to allow the user to name the
analysis type as well, and have the icon with the name the user gives?
The idea here is that 'Frq. 1', 'Frq. 2', and 'Frq. 3' parts are
eliminated from the interface as is, but each would appear as a
separate analysis tab, one for each data type analysed. For icons I
would suggest using those of the Oxygen theme as we should be able to
freely use these and bundle them with the program
(http://www.oxygen-icons.org/)! On my system (Mandriva 2010.0) all
the PNG icons are located in /usr/share/icons/oxygen/. SVG is also
there and if possible to use would be awesome! It's 132M in total.
We might have to ask the Oxygen people about it.
Or we could bring up a dialog that displays the parameters for the
calculation and the user can accept and start the calculation or cancel
and change values?
The automatic protocols are already coded, they are what you have
already in the GUI. They are just spread into tabs either along the
left hand side ('Model-free', 'Results'), along the top (i.e. in 'Frq.
1', the tabs 'steady-state NOE', 'R1 relaxation', and 'R2
relaxation'), and in the results tab (as the 3 different boxes). The
analysis types already present in an automatic form can be isolated
as:
steady-state NOE analysis,
R1 analysis,
R2 analysis,
Model-free analysis.
In the future, I would like to add the other analysis types such as
'N-state model', 'Frame order theories', 'J(w) mapping', 'consistency
testing', 'relaxation dispersion', etc. I really think each analysis
type should be isolated, in its own tab (maybe being closable), has a
button to describe to the user what is happening, and a button to view
the results. This may not be what you had initially in mind. Can you
see another way in which these other analysis types can be supported?
I just changed the select_model_calc.py script, so only automatic mode
and local tm calculation are enabled. Only after successful local tm
calculations, the other models ar enabled.
This is hidden from the user. All they see is that they input the
files and parameters, and then they click on 'Execute relax'. 100% of
everything else is automatic to them. By automatic I mean that the
GUI does everything without the user creating data pipes, calling user
functions, etc. There are thousands of possible different ways of
performing model-free analysis and the GUI only provides 1 - and this
is automatically done behind the user's back. Hence they need to be
told what is happening. If I ask for model-free, I have to be told
the protocol utilised.
d) Then there could be a series of buttons for all the user input
required. Or boxes, etc. For model-free analysis, I would suggest
the design to be similar to the 'full_analysis.py' script (the concept
is similar for all the automatic methods). Firstly the script can be
imported to obtain the defaults. This also gives us access to the
docstring which could be formatted and placed in an info window, maybe
accessible through a button or even the model-free analysis icon.
This would be extremely useful as the user will then know what the GUI
is doing.
as above
e) I would suggest breaking up the results tab. These ideas can be
incorporated into each separate analysis tab.
f) Maybe for the interest of users, there could be a 'view script'
button that on-the-fly generates a script (maybe savable) that would
be equivalent to what the GUI is executing?
Do you think such as the bruker function of NMR Pipe?
This is not a NMRPipe GUI but a simple program used to generate
scripts with the necessary parameters read (often incorrectly) from
the FID data files. The GUI for NMRPipe is NMRDraw, but most people
don't use this part of the GUI. This type of functionality of the
'bruker' and 'varian' programs is not needed for relax as all the user
needs to do with the full_analysis.py script is use a text editor to
change a few values. The GUI is used to drive the program, it lets
the user interact with the program. And it is part of the program.
This idea (8f) is just an idea for the future. This is not needed for
publication. And it is not needed for the operation of the GUI or the
program. It's just for the curious user who would like to know what
is happening under that pretty interface.
There are a lot things to improve the flexibility and appearance of the
GUI. Another proposal would be that relaxGUI opens a log-dialog, which
displays what's going on. The only problem there would be to catch the
output of the relax functions (such as minimise). A big advantage would
be that we could have a progress bar that shows the user where the
calculation is (not working for model free analysis, as we don't know
the number of iterations).
This is easy! It's already all coded (see relax_io.DummyFileObject
and the logging and teeing capabilities of relax). I can provide this
for you, both STDOUT and STDERR as file-like objects (i.e. you can
read from them to get the contents). You just need to use readlines()
and put the contents into the text canvas.
This brings me to another issue. I would like to limit the max number
of iterations (let's say to 100), so the automatic mode can proceed even
if the calculation has not converged. Then we could even use a progress
bar (it would jump if the calculation finishes earlier than after 100
iterations).
I would say 40! It should be done in maximally 20 iterations. I have
now solved the problem of infinite iteration in the full_analysis.py
script, so this can be used as well. A progress bar for the
iterations would be useful, but also for the other parts of the
analysis. This could be done through watching the log in a window, or
by a more advanced progress window with a few progress bars and maybe
text shown for each API call made (i.e. like each user function).
But to be honest, I would like to get this version running so we can
publish it. Then we can add new functions and more flexibilities. What
do you think?
I would say that the current version looks good but is not publishable
as it is. This is to be used for scientific research, so the
protocols must communicated to the user. Optimisation algorithms,
model-selection methods, error propagation methods, etc. In an
application paper, you need to write that you used this or that
method/protocol. You don't say you performed relaxation analysis and
model-free analysis in relaxGUI 1.00 in the methods section and that's
it. There are numerous small issues as well:
For example in the NOE picture, the line goes from a proton to an
oxygen, rather than proton to proton.
The fact that you can't explicitly save the relax state will also be
an issue for many users. The relaxGUI settings that are saved with
'File -> Save as' is not what the user will expect - they will think
that the data component of relax will be saved, they will assume -
correctly - that this will be a relax save file. The user will not
make a distinction between the GUI code or relax itself, to them it
will all be one and the same. Maybe this could be 'File -> Save
program settings'. And maybe the automatic saving of the final
results could be removed. So then the user has to click on 'File ->
Save as' to produce the relax save file. But I would really just
store everything that goes into the *.relaxGUI file in the relax data
store and save the lot when clicking on 'File -> Save as'. Having
separate relaxGUI save files and relax save files is not logical.
For publication it will be much better to have this in relax version
1.3.5 rather than sitting in a branch. It would be far simpler for
the user. Those who have no problem checking out source code and
compiling the relax C modules will also have no problem using the
scripting interface, so limiting the GUI to those users would be bad.
But note that I will refuse to merge code which does not meet the
project standards. This has happened with the chemical shift tensor
branch (https://mail.gna.org/public/relax-devel/2008-12/msg00045.html)
where the support for a rhombic CSA not collinear with the dipole
interaction, and multiple NOE relaxation sources was added. This is
in a branch (http://svn.gna.org/viewcvs/relax/branches/cst_1.2.10/)
and was going to be published. But now the code is totally dead! The
developers are lost in action and the code will, in its current form,
never be merged into the main line. Users will not use this code and
the authors will not receive citations when they could be getting one
citation per RNA/DNA dynamics analysis published. I would prefer that
this doesn't happen to the GUI code as well.
Regards,
Edward
Re: Designs for the relax GUI.