2010/1/11 Michael Bieri <michael.bieri@xxxxxx>:
Hi Edward
I think the problem is that the initial relaxGUI was designed as a
one-file script to be executed by the relax command. As the whole
program was reformatted and split into different files (to simplify) and
the prompt commands were exchanged to API commands, there are lots of
changes.
This is exactly how relax started as well. It was simply a script
used to run Art Palmer's Modelfree4 program and process the results.
It was originally called modelfree, then mf, and finally relax. You
can see the original modelfree script(s) by checking it out from the
repository using:
svn co http://svn.gna.org/svn/relax/0.1 v0.1
For a laugh, you can even see my very first initial script I wrote:
svn co http://svn.gna.org/svn/relax/0.1@r1 v0.1_start
here you'll find the file 'old_scripts/modelfree.pl' which is my
original perl script I wrote during my honours year in the Gooley lab.
The first revision of relax was just a translation of this 1500 line
script into python. Since then the program has evolved hugely, but
only by taking numerous very small steps.
I don't know anything about software development, but I think
before committing every changes, there should be a program that works.
I also started with zero knowledge about coding. As for having a
functional program when committing, for a branch this is not necessary
at all! Most of my branches have stages whereby the code is
non-functional. It just has to be functional, clean, and properly
written before being merged back into the main line.
I
haven't even started to incorporate the settings. The only changes are
simplified:
split the huge relax_gui.py file,
This I have already committed.
convert prompt commands to API (model-free part still not working),
This is not in yet. It is a real pity that this has not been
separated - that would have really have helped me to help you to get
everything functional. I could have commented on how to do things
better, correctly, etc.
deleted easygui.py and wrote filedialog.py and message.py,
I think I have this committed already.
minor cosmetics such as T2 to R2 and '/' to os.sep.
These should have been separated :S These small changes completely
hide the important changes that I really should be helping you with.
Would it be possible to separate these out? I.e. take the repository
version (many times if necessary) and re-make these changes. So there
is one patch for T2 to R2, one for os.sep, etc.?
The other thing that is hiding the change from generating and running
a relax script to plugging directly into the relax API is that there
are GUI interface changes :(
As the current shape of relaxGUI looks (almost) as the final version
(only integration of settings parameters and fixing model-free
calculation), I think your mentioned exception to write a huge commit
would be ok. Then, I will commit every single changes as a new message.
Last year, I tried to upload a commit, but I got some error messages. Is
there something special that has to be applied?
Ah, you don't have commit access yet! First you have to prove you can
create proper commits (i.e. only contain one type of change) with
informative commit messages. Then after I apply a few of these and I
and the other relax developers are satisfied that your skill level is
good enough, we will have a vote to grant you commit access. Only
then will you be allowed to modify the relax repository. Therefore
for this large patch, would you be able to write the commit message
and then post it on the mailing list? I can then apply the patch with
the message.
If your developments are too fast, in the near future as an
alternative, we could grant you limited rights to modify just the
bieri_gui branch. See how it goes with submitting small patches
together with their commit messages first (both attached to
https://gna.org/task/?6847). If I can't keep up with you, I can
discuss this idea in private later on with the other developers.
In general I think the idea of commit every changes is a very good idea
and may help to organize the software package (especially when becoming
too complex).
I can't emphasize how important this is :)
So let me know if this is ok for you.
It is ok, but I might try to first fix a few of the basic cosmetic
changes and commit these separately (i.e. a new patch will be needed).
There are a number of problems still, but it is impossible to comment
on almost 8000 lines of changes in one go! One, for example, is that
the import statements using '*' must be eliminated. The "from xxx
import *" notation is a debugging nightmare as it can unknowingly
overwrite things in the namespace of the importing module. It can
take days to debug these oddities. Others include how to better
integrate into the relax API and also how to make the interface more
flexible. Note that I'm not interested in the final product when
looking at the changes - I'm interested making sure the code is good,
even if the user will never see that. This will make it easier to
maintain or extend the GUI in the future, even if you stop developing
it.
Cheers,
Edward
Re: [task #6847] The Bieri graphical user interface.