mailMore GUI design ideas!


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

Header


Content

Posted by Edward d'Auvergne on January 21, 2010 - 10:33:
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'.


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.


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.


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!


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

Regards,

Edward



Related Messages


Powered by MHonArc, Updated Thu Jan 21 23:40:09 2010