1) Each new analysis appears not as tabs but as a new window. This
would be similar to oowriter or MS Word, where there is a 'Window'
menu where one can switch between the analyses. This is also similar
to what sparky does. Either there is an entire new window for each
analysis, or it could be done as now where each is in a tab (just that
you don't show the tab bit). Each analysis can be created at any
time, and closed at any time. The window with buttons with pictures
of each analysis type can appear at the start and also when clicking
on 'File -> New analysis'.
I somehow like the idea that the whole relaxation analysis is in one
window, separated by tabs. This helps to keep all the informations
together. I would suggest to split the kind of dynamics calculation,
i.e. model-free, dispersion....
These could be grouped - the R1, R2, and NOE. But I would still try
to make this flexible and not assume a protein NMR spectroscopist has
measured these standard things at 2 field strengths. What if a
chemist came with R1 data collected at 100 different field strengths
using special equipment? The point here is that you should not force
upon the user a way of doing something because some user will always
want to do something differently. If they can click on 'File -> New
analysis' and select R1 from the analysis selection window, and repeat
this 100 times, they would not complain about relax. relax can do
this without problems so this would be a constraint on them 100%
enforced by the GUI. It should be dynamic - I want to add this type
of analysis, save then close this one, etc. It makes the GUI coding a
bit more difficult but improves the usability and power of the GUI
immensely. I have specifically designed relax to be incredibly
flexible, allowing the user through the prompt and script interfaces
to do almost anything they can imagine. Most will just use
pre-written scripts, but this flexibility is incredibly useful. I
would be very sad, that if after so much effort designing a program
with so much flexibility (almost any type and amount of data input)
and support for all types of systems (small molecules, RNA, DNA,
proteins, sugars, etc.), that the GUI then takes this all away :(
2) The code paths are too complex! This can be done after the paper,
but please don't discount this. If I would like to make modifications
to or debug the model-free code (GUI and calculation), I have to jump
all over the place and have to separate it in my mind from all the
other code. I would suggest a big rearrangement of the code, to make
it more like lego where you have reusable blocks. Firstly, what does
the directory 'res/' stand for? I cannot for the life of me work out
why you have this directory! I would propose the following, logical
directory structure:
gui_bieri/ -> All the GUI element modules (filedialog.py,
settings.py, etc) go in the base directory. In the future when the
interface is more complex, the GUI elements could be grouped and
shifted into packages (directories).
gui_bieri/analyses/ -> All the analysis specific code goes here.
I.e. 'gui_bieri/analyses/model_free.py', 'gui_bieri/analyses/r1.py',
etc.
gui_bieri/oxygen_icons/ -> Have dedicated directories for material
that is differently, but legally licenced! The may shift down a
directory to the base relax directory when other types of GUI are
added.
gui_bieri/images/ -> All the bitmap pictures go here. I would
suggest that for the future of the project, that SVG versions whenever
possible are placed here. This will allow for better image resizing,
tiny icons to be made, etc.
gui_bieri/execution/ -> All the calc_* modules can be shifted here.
Or alternatively it goes into gui_bieri/analyses/ as well.
sure! I just placed everything into the res (from resources) folder. but
it's getting messy and overfilled now!
Give the word and I'll make all the file rearrangements necessary in
the repository. If you make any changes during this time, you will
need to manually shift the changes around (move the modified files to
the new locations). I would also like to have some point in time
reserved for the whitespace fixes. This is very important! I cannot
emphasise this enough!
3) Code recycling. Many analysis types re-use the same user
functions. For example model-free, J(w) mapping, consistency testing,
and in the future SRLS and other analysis types will all use relation
data input. Therefore this GUI element could be separated and each
analysis type then places where it likes. I would suggest that it
looks as follows (100% redesign). There is a canvas (forgotten the
GUI element name here) which displays the loaded relaxation data,
displaying a label (ri_label and frq_label will soon be combined so
Sebastian can better work with relaxation dispersion data) and the
frequency in MHz. Each can be selected by clicking on them. Then
there are a series of buttons on the right hand side. A big + icon
adds new data, and opens a dialog box to select the file, specify the
label, the frequency, all the column numbers, the column separator,
and allowing a spin_id selector to only load a specific subset of the
data. A big - icon can remove data. Another icon can display the
data for all spin systems. Therefore I would suggest a module called
'gui_bieri/relax_data.py' for this that can be imported by
'gui_bieri/analyses/model_free.py'. The relaxation data input GUI
element can then be modified/expanded at any time independent of the
rest of the GUI.
I would suggest to have an initial window that shows which calculations
(modelfree, J(w)...) can be performed by relax. Under these buttons, we
could have a list or tree that shows projects that are already
calculated or in the middle of analysis. So users can either start a new
analysis or continue.
I don't think the tree is necessary as we could switch between them
through the 'Window' menu. This is the standard way to perform this
in most programs.
As for point 3), I was talking about the data input for an analysis -
i.e. the current model-free 3 frequency relaxation data input table.
This is not related to the analysis selection window that can appear
at the start and after clicking on 'File -> New analysis'.
4) PyMOL (http://www.pymol.org/). This is open source and can be
imported as a python module. Therefore I propose as a future idea
that we bundle this with relax, import it in
'gui_bieri/molecular_viewer', and provide its OpenGL canvas to display
the results of the analyses to each analysis type. Not the PyMOL GUI
- this sucks - but the OpenGL canvas GUI element. This could possibly
appear in a new window, as a new tab, or even as part of the main
window using buttons to switch rather than tabs. We can then provide
relevant functions as menu entries - 'Display diffusion tensor',
'Display data' where S2, te, Rex, CSA, J(0), J(wN), etc can be mapped
onto the structure, 'Write PNG', 'Ray trace', etc. This would make
the relax GUI much more awesome!
this would be very cool!!
It would be, and many people are interested in this and what it can do
for relax. It would also allow 3D geometric object to be drawn, which
for dynamics could be very useful. Or even to generate alignment
tensor pictures attached to the molecule.
what do you think about the future of relax? do want to drive it in a
more GUI like application, so future elements are designed together with
a GUI?
This has been decided a long, long time ago. It is all written out in
the relax manual in section 9.7, 'The core design of relax'. The
different user interfaces are all part of the program, but note that
relax is a massive software project. Therefore to keep this codebase
sane and alive, there are clear APIs between different parts of the
program. And the UI's must respect these. If new functionality is
needed, it is added to the correct part of the code base and accessed
through these APIs. 'generic_fns' is easy as this is just a bunch of
functions to import. 'specific_fns' is more advanced and a cleaner
API. This is for the different analyses where they must provide
certain methods so that minimisation, for example, just works without
modification to the minimisation code. The permanent data storage is
in the relax data store - with no exceptions. These APIs will stay,
and will become more and more refined as the program evolves.
My contributions to relax are currently in the areas of the N-state
model and Frame Order theories. These are different in that RDCs,
PCSs, NOEs, J-couplings, etc. are being used to obtain dynamic
information. In the case of the N-state model, this is being used to
solve stereochemistry questions in chemistry. The Frame Order
theories will hopefully be completed soon and presented at the ICMRBS.
Other people are taking the program in other ways, for example see
the next paragraph.
Note that the GUI is only one of many UI's that will go into relax.
Another one planned is a web interface allowing a user to run
calculations over the internet. One use that Gary Thompson has talked
about is to set up a server that people can submit relaxation data to,
and have the final model-free results returned to them. So the web
interface and the multi-processing code will very naturally fit
together. Then there are the script and prompt interfaces that those
with massive clusters will probably want to always use. Other
interfaces have been proposed in the past, and may return in the
future.
I also use relax as a toolkit. I can write python scripts and import
and use relax functions (just by running the python script as a relax
script). This gives me instant access to a PDB reader/writer, to many
mathematical functions, to the convenient relax data store that I can
use to store atom specific data (unrelated to dynamics). The
generic_fns.mol_res_spin.spin_loop() function is incredibly useful!
I am currently also working on a software that analyzes dispersion data
(at the moment cp-CPMG). There, I completely build everything in a GUI,
which facilitates a lot of issues about preparing input files. Peak
files are just loaded in an excel-like grid. Users choose which are
residue number columns and data columns. Like this, a lot of formatting
problems are avoided.
If you would like, we could fuse these programs as well!
I suggest you talk to Sebastian Morin (https://gna.org/users/semor) as
he is the owner of the relaxation dispersion branch
(http://svn.gna.org/viewcvs/relax/branches/relax_disp/)! We are
currently designing how to input the base data, and this will probably
result in the 'ri_label' and 'frq_label' being merged into one.
There is another idea:
Wouldn't it be great if the user only needs one HSCQ assignment (or
TROSY for better dispersion data) and relax(GUI) reads in all the
recorded spectra, finds peaks, groups them and start the analysis? This
would be a really fat automatic software!
This can be done without problem. For the relax design, the GUI would
fully control this, but most of the work would be performed by
functions in the 'generic_fns' package. User functions can be
designed at the same time or afterwards. For example spectra.read()
would be a useful user function that then performs the same thing as
the GUI, both going through the API and calling a single function in
the 'generic_fns' package. Both can be written at the same time (see
the test suite comments below for why this should be done). This
function would then store this data in the relax data store.
Who ever implements this would end up with a very impressive paper.
People are looking at automatic structures (raw spectra to final
structure) but no one that I know of is trying to do the same with
dynamics!
The main issue would be to have a good peak picking algorithm included.
I know that Mehdi Mobli (IMB) is writing a promising one. We will have a
collaboration about dynamics in 2 weeks and I could ask him to join.
What do you think about this?
If you'd like this in relax, you are totally free to do this. And it
would be a most welcome and awesome addition! But it will need to
follow the relax design with the clean code separations. You will
need to familiarise yourself more with the overall design of relax.
And also improve your coding abilities - i.e. more comments, no
whitespace issues, module/class/function docstring writing, commit
messages following the rules, etc. You'll have to do this to avoid
jumping on other peoples toes and breaking their code. You will need
to understand the test suite, and implement user functions at the same
time as GUI functions so scripts can be written and, together with
basic test cases, added to the test suite. I would suggest carefully
reading all of chapter 9 of the relax manual.
It will be difficult to come to grips with this huge code base, but in
the end it should be worth it. And I and the other relax developers
can guide you through this jungle.
There is a lot we can do to get relax THE software for protein dynamics!
It's already there ;) Art Palmer is recommending people to use relax
rather than his program! I'm extending the program to other analysis
types. Sebastian Morin as well. Gary Thompson worked hard on
parallelising relax to run on massive clusters, and soon people will
be able to benefit from that. Chris MacRaild has made many numerous
improvements all over the code base, important things that everyone
now takes for granted. BMRB support is coming very soon which will
allow smooth flow of dynamics data into that data base. CCPN support
is planned for the future (I was just talking to Rasmus today).
Others are planning on expanding relax to other domains - for example
to revolutionise dynamics and its understanding in chemistry.
But adding a flexible GUI will make relax even more awesome! And an
automatic process - from raw data to dynamics description - would be
huge. But I seriously expect that each one of these new additions
would result in a paper - otherwise I would be disappointed.
Minimally a very short communication of a few paragraphs must be
written.
Cheers,
Edward
Re: More GUI design ideas!