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