On 1 February 2010 04:08, Michael Bieri <michael.bieri@xxxxxx> wrote:
Hi Edward
Oh my god, you made a lot of changes! I am now trying to understand this
way of programming. But respect, there is a lot of smart stuff in it!
Most are invisible on the surface though ;) But, yes, there are a lot
of core changes. I did this to get model-free up and running, by
having the data in the relax data store and then passing this through
the clean API separating the GUI from the calculation code - the
dAuvergne_protocol class. But many changes are only to one small part
of the code, I have made many of these to show you a good way to
design the code. By studying these, you should be able to advance the
GUI at a much quicker rate and the changes give you more power to
control the GUI.
For example to pack a new R1 analysis frame into some wx object
(notebook, box, etc), first import:
from analyses.auto_r1 import Auto_r1
add it to the list of analysis frames (this dynamic adding won't work
quite yet):
self.analysis_frames.append(Auto_r1(self, object))
and it will be added to the object. I would like to clean this up
more after the NOE code is out of relax_gui. Currently a
notbook.AddPage() command is necessary to see this frame. The idea is
to be more dynamic, to allow a menu entry 'File -> New analysis' to
bring up the analysis selection window
(https://gna.org/task/?6847#comment33), to allow chemists to easily
add a new frame for the N-state model, to all me to add a new frame
for the frame order theory, etc.
There is one easy starting point for learning these new changes - the
automatic NOE calculation frame. I have made the copy
'analysis/auto_noe.py'. If you like, you can have a go at this. The
first commit would be the deletion of all the non-NOE code. Then
mimic what happened with the changes to auto_rx_base.py (r10526
onwards, https://mail.gna.org/public/relax-commits/2010-01/threads.html).
This will show how to have a clean code separation between different
parts of the GUI.
I try to get along.
If you have any questions, please don't hesitate to ask.
So you basically made the calculations (execution)
independent from the log window.
This is logical. Anyway, you had made the calculation part
independent already by launching it in a thread. If you close a
window, the calculation should not terminate. And this allows the
user to keep using relax. The point of this would be to not have to
wait to calculate the R2 while the R1 is running.
So it can be opened and closed anytime.
>From the progress bar and the cancel button, and the discussions, this
is a lot more than just a log window. It can control the relax
calculations. So to be able to access it at any time, and close it,
would be useful.
I also like the dAuvergne protocol. This honours you as it should be.
The user will not see this though, it's completely behind the GUI and
is part of an API. It just identifies it as what it is, and the
separation into it's own class prevents the protocol from being broken
by accident by other parts of relax (i.e. the GUI or user scripts).
But I think we should make a copy for the gui, so the progress bar can
get updated.
This is not good coding style! One should never make a copy. This is
why the rhombic CS tensor and multi-dipole branch will never be
accepted into the main line - there the duplication has happened 6
times or more. If new functionality is needed, this is added to the
original. Then the other parts of the program which use this common
code base can also benefit. Duplicating the code is the quickest and
easiest for a developer to have something operational. But it is not
maintainable, it is a nightmare to keep syncronised with changes in
the original, and it is a nightmare for debugging. Code duplication
is just not acceptable.
Just add some wx.CallAfter(blabla for progres bar).
This is one way, the easiest, but not the best as it breaks the clean
code separation that is necessary in large programs. Another way is
for the relax controller to run in a thread, continually checking the
progress by reading the data from the progress container I suggested.
Just a few timer waits, read the variables, and update the window as
needed.
I think
we should limit the amout of iterations to 30.
This can be added to dAuvergne_protocol as a new keyword argument,
something like 'max_protocol_iter'. The termination then occurs
behind the API. This is not a GUI concept but part of the calculation
code.
Then we can update the
progress bar accordingly. This is especially relevant for the full
automatic analysis.
For this, a lot more information can be given that is specific to this
analysis. I.e. the iteration number for the automatic model-free
protocol. The relax controller could be made to be different for
different analyses, and include separate MC simulation progress bars,
etc. Just ideas for the future.
For 'manual' auto-local tm calculation, the progress
bar could jump in 1/9 steps, so the user can see which model is
calculated (has to be adapted to the selected models).
What about 2 progress bars for this? One for the model, and one for
the number of spins completed? All this information can be put into
the progress container by dAuvergne_protocol to be then read by the
relax controller.
For the remaining
models (m1-m5), we could set the progress bar to 100% after 30
iterations. If it converges earlier, it could jump. What do you think
about this? This would improve the feedback of the gui enormous.
Information about the iteration position would be very useful to have!
The relax controller could be made very powerful in this way -
progress bars, status bars, log, etc. It is a good idea though. I'm
just wondering if there is another way to show this? Maybe print the
iteration number as well?
A minor remark. I would suggest to use smaller images for the rx ad,
remove and refresh buttons. Maybe 16x16 would still be ok. I would like
to keep the gui clean. Even just simple '+' and '-' would be nicer.
For this I just kept your original 60 pixel width. It could be made
smaller though, they are quite big. The idea for bitmaps is that
almost all buttons in computer programs come with pictures. The text
is often optional now. Look at the buttons at the top of any program.
Which program's design are you following for your design? We
shouldn't be reinventing the GUI wheel here.
All the data handling is very impressive. I still have to fully
understand this (line by line).
Again, if you have any questions, don't hesitate. This is quite a
different concept.
I will play around with the version I have at the moment and try to add
some new features. But I think we are on the good way of having a
version 1.00 ready.
It is close. Is the version you have r10605 or higher? Do you have
the model-free calculations running? If you have any patches, please
specify the revision number ('svn info').
I think there are a few more things to fix, as the NOE, R1, and R2
calculations are not running through the relax controller. I have
removed the R1 and R2 calculation code (again this is code
duplication) and I will provide the resources to have this running
from a module in 'auto_analyses'. A good way to think of this is as
follows, just put yourself in the shoes of the person in the future
developing the web interface for relax. They would like to do exactly
what you are doing, but with HTML and scripting. How can they then
access and use the progress information? If it is tied into your GUI
code, they cannot. That is why you put this type of code into
reusable modules which are not part of the GUI. The GUI only provides
input and feedback to the user, nothing else. If you need to modify
the relax code base to provide new features to the GUI, then the relax
code base should be directly modified!
Cheers,
Edward
Re: Status ideas for the relax controller.