Hi Michael,
Now that I've applied your patch_II file in pieces, I have a much
better understanding of your code base and how to improve it. Below
are a number of separate design ideas. Before any of these happen, it
would be best to have any code changes you now have applied.
1) Formatting - this needs a complete overhaul. This is a major
hindrance to anyone else trying to contribute code and must be fixed
ASAP. The major issue is whitespace problems. The
'scripts/code_vadidator' script should not indicate any problems for
all modules (exceptions can be made in certain special cases).
2) Import fixes. All 'from xxx import *' statements need to be eliminated.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
What do you think?
Cheers,
Edward
Designs for the relax GUI.