Hi,
I've had a look at the code for this now, and have a few suggestions
there. This is about the design, and will help in learning how to
modularise your code. I have numbered each section for future
reference.
1) The class name should start with a capital letter.
2) Note there is no class docstring at the moment.
3) The __init__() docstring needs a few fixes. To be a docstring, it
needs to be at the very top with no newlines and no comments between it
and the 'def xxx()' part. So:
def __init__(self, *args, **kwds):
# docstring
'''Start up dialog to choose analysis mode
Users can choose between analysis methods, relaxGUI will
collect results and summarize them in model-free calculation'''
should be:
def __init__(self, *args, **kwds):
"""Start up dialog to choose analysis mode.
Users can choose between analysis methods, relaxGUI will collect
results and summarize them in model-free calculation.
"""
Note that ''' is now """, there are '.' characters at the end of
sentences, the last """ is on a new line, and there is no indentation
within the docstring (epydoc will fail when running 'scons
api_manual_html').
4) __set_properties() and __do_layout() are bad for modularity of the
code and should be eliminated. Try to create a method for each button,
like I have done in the model-free frame. Then shift the code from
__set_properties() and __do_layout() into these. I.e. each method
should create the button and text, set its properties, perform the
layout inside the button, and set the Bind event. In this case, I would
actually write a single method that returns a GUI object for each button
(in this case the sizer box). It would accept as keyword arguments all
the specific things - text, image, tool tip string, and method to bind
to the button - and then generate and return the button. Also, I would
write a method to create the main window. Try to have a method for each
GUI element, i.e. try to isolate each element so the code structure
resembles lego.
Cheers,
Edward
On Wed, 2010-01-27 at 01:35 +0100, Michael Bieri wrote:
Follow-up Comment #33, task #6847 (project relax):
Hi Edward
This is an proposal for the initial start-up dialog, where users can choose
analysis. All teh required files are in the zip file. it is a normal python
script ($ python start.py). all the images have to be in the same folder.
This is just to test and has to be changed.
It should work as follows:
The user selects an analysis method (noe, r1, r2, modelfre...). relax stores
the results internally.
One the user chooses modelfree, there should be a prompt that asks if
existing or calculated (from relaxGUI) data should be used (imported).
Every window is like a tab in the current version.
For model-free analysis, noe and rx files can be grouped by the
list.append()
function of python and handed to the dauvergne auto-analysis. Like this, we
are not limited with the amount of input files. There should be a checkpoint
for minimal requirements.
What do you think about this?
Cheers
Michael
(file #7811)
_______________________________________________________
Additional Item Attachment:
File name: start_dialog.tar.gz Size:26 KB
_______________________________________________________
Reply to this item at:
<http://gna.org/task/?6847>
_______________________________________________
Nachricht geschickt von/durch Gna!
http://gna.org/
_______________________________________________
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
Analysis dialog (Re: [task #6847] The Bieri graphical user interface.)