mailRe: More GUI design ideas!


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Michael Bieri on January 21, 2010 - 23:26:
Hi Edward


Edward d'Auvergne schrieb:
Hi Michael,

I've been thinking of how to better design how different analysis
types are handled in the GUI, and have a few ideas.  What do you think
of the following?

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....


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!

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.


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!!


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?

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!

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! 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?

There is a lot we can do to get relax THE software for protein dynamics!

Cheers
Michael

These are just a few ideas of many that I consider important.  What do
you think?

Regards,

Edward

_______________________________________________
relax (http://nmr-relax.com)

This is the relax-devel mailing list
relax-devel@xxxxxxx

To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel




Related Messages


Powered by MHonArc, Updated Fri Jan 22 01:20:15 2010