User:Aakash: Difference between revisions
| Line 21: | Line 21: | ||
- In the Study dialog, | - In the Study dialog, | ||
1. Remove "Units" from the right-hand side of the inputs. | |||
2. Make sure that checking of inputs is performed. | |||
3. Boxes with invalid input should be highlighted pink. | |||
4. The number of steps should be a user preference. | |||
5. Input focus for keyboard should be in the "lower bound" box when the dialog pops up, with the text selected so that use can start typing immediately. | |||
6. Does the box work properly when units are omitted? Did you re-use the code for this input box from elsewhere? | |||
- Yes, it wont proceed unless valid input is provided. Some of the code for checking Atom entries was taken from properties.py | |||
[[File:PyGTK Study - 9.png]] | [[File:PyGTK Study - 9.png]] | ||
| Line 33: | Line 34: | ||
- In the Study dialog, | - In the Study dialog, | ||
1. Add a check-box saying "continue on failure" and have the box checked by default | |||
2. Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up) | |||
- A new "Study Reporter" dialog should pop up for the actual STUDY calculation. This should be a specialised form of the Solver Reporter that is adapted for reporting the progress of multiple attempted solve actions. There should be a progress bar showing how many of the "points" (not "steps") have been solved/attempted. The usual Solver Reporter should not appear. | - A new "Study Reporter" dialog should pop up for the actual STUDY calculation. This should be a specialised form of the Solver Reporter that is adapted for reporting the progress of multiple attempted solve actions. There should be a progress bar showing how many of the "points" (not "steps") have been solved/attempted. The usual Solver Reporter should not appear. | ||
| Line 41: | Line 42: | ||
- In the Observer tab | - In the Observer tab | ||
1. After a model is reloaded, a right-click in the "dead" Observer table results in an error | |||
2. If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc) | |||
3. If an observer tab is "dead" then the "add" button should be greyed out. | |||
4. Can you work out a way to remove a column from the observer? | |||
- Will do it. | |||
5. What happens when a column is added to an observer that already contains a number of rows... does it work OK? | |||
- Yes, it works Ok | |||
6. If possible, can we "flag" a row in the table as being a "problem row" if the solver was not converged at the time the data was "kept". eg perhaps the font can be red, or there can be an icon at the left of the table? | |||
- Should be possible, need to see. | |||
- If there are multiple Observers, does everything work OK? Check carefully. | - If there are multiple Observers, does everything work OK? Check carefully. | ||
- As far as I checked, it was fine, will do more checking though. | |||
- Plot button | - Plot button | ||
We need to work on more flexibility of plotting. The first thing is some way to indicate "x" and "y" variables for a simple plot. Perhaps you could try hand-drawing some sketches of possible GUI implementations, and scan/photo them and send me? This is a slightly different topic, but it all goes to making the "observer" tab a useful tool for working with out simulations. | |||
Revision as of 12:50, 10 July 2011
Aakash is a Google Summer of Code 2011 Student. He has undertaken a project for GUI Improvements & Bug Squashing for the PyGTK GUI.
Development branch: aakash:
Project goals
The primary goals, in order of importance would be –
- Porting extra features of old GUI to the new GUI.
- Addition of requested features. (will think of some too)
- Add whatever more that the GTK library has to offer.
- Check for and fix bugs in my code.
Progress reports
10 July 2011 Working on improving the Observers, Study and Plot functions in PyGTK GUI. In an e-mail John sent me on 8th July, he pointed out some bugs and gave many suggestions. I have categorised them here in two parts, depending on the status. -
- When right-clicking in the Simulation tab, the "Study" option should only be available for Fixed variables. Otherwise it should be greyed out.
- In the Study dialog,
1. Remove "Units" from the right-hand side of the inputs.
2. Make sure that checking of inputs is performed.
3. Boxes with invalid input should be highlighted pink.
4. The number of steps should be a user preference.
5. Input focus for keyboard should be in the "lower bound" box when the dialog pops up, with the text selected so that use can start typing immediately.
6. Does the box work properly when units are omitted? Did you re-use the code for this input box from elsewhere?
- Yes, it wont proceed unless valid input is provided. Some of the code for checking Atom entries was taken from properties.py
- In the Study dialog,
1. Add a check-box saying "continue on failure" and have the box checked by default 2. Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)
- A new "Study Reporter" dialog should pop up for the actual STUDY calculation. This should be a specialised form of the Solver Reporter that is adapted for reporting the progress of multiple attempted solve actions. There should be a progress bar showing how many of the "points" (not "steps") have been solved/attempted. The usual Solver Reporter should not appear.
- When the process has finished, the box should disappear if there were no errors. Otherwise, the box should stay there, and there should be a "label" that reports the presence of errors (see below for flagging of "problem rows"). Details of the failures can be shown in the "error" tab for the moment.
- In the Observer tab
1. After a model is reloaded, a right-click in the "dead" Observer table results in an error
2. If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
3. If an observer tab is "dead" then the "add" button should be greyed out.
4. Can you work out a way to remove a column from the observer?
- Will do it.
5. What happens when a column is added to an observer that already contains a number of rows... does it work OK?
- Yes, it works Ok
6. If possible, can we "flag" a row in the table as being a "problem row" if the solver was not converged at the time the data was "kept". eg perhaps the font can be red, or there can be an icon at the left of the table?
- Should be possible, need to see.
- If there are multiple Observers, does everything work OK? Check carefully.
- As far as I checked, it was fine, will do more checking though.
- Plot button
We need to work on more flexibility of plotting. The first thing is some way to indicate "x" and "y" variables for a simple plot. Perhaps you could try hand-drawing some sketches of possible GUI implementations, and scan/photo them and send me? This is a slightly different topic, but it all goes to making the "observer" tab a useful tool for working with out simulations.
7 July 2011
Just added the following features, as requested by John in a discussion held on 5th July -
1. Allow right-click in the Observer tab, so that if the user has selected a number of variables, they should then be able to do a study on any variable that's already selected.
As you can see in the screenshot, you can study any variable by using the right click menu.
2. Remove selected row(s) from an Observer table.
Now, this can be done in two ways- either by using the right click menu, or by selecting the row and pressing the "BackSpace" or "Delete" on the keyboard.
3. Clear the whole thing (but keeping the list of variables being 'observed'). - Was Already there !
4. Ability to delete an Observer tab, i.e., a close button with a confirmatory dialog box.
4 July 2011
I have implemented the STUDY functionality in the PyGTK GUI partially. Its working for linear distribution of one variable. I need to complete it for the logarithmic distribution, that should not take much time. It is slightly different from what I had planned earlier.
Usage -
1. For all variables you want to watch, first you need to 'Observe' them.
2. Then, just right click on the variable you want to "Study" and select Study.
3. In the dialog box, one can set the upper bound, lower bound, number of steps, distribution type (linear or logarithmic) and there is also an option to run a particular method before each solving. For convenience, it retrieves the lower and upper bounds of the variable as mentioned in its properties.
4. Clicking on OK does everything, and the results can be seen in the Observer tab.
1 July 2011
Implementing the STUDY function in PyGTK GUI now. Had a discussion with John, and for the beginning it will only be 1-D, i.e, we will be varying only one parameter. The implementation will work together with the 'Observers' functionality which is already there.
The idea is that the user can 'observe' all the variables to be studied. Then, one can select which one of them will be varied. There will be a dialog box for setting the upper bound, lower bound, number of steps, distribution type (linear or logarithmic) and an option to run a particular method before each solving. We have also thought of adding a feature where the output data could be written to a file during the solving.
I plan to make it something like this -
27 Jun 2011
Almost completed the port from libglade to GTK Builder. A few warnings related to missing signal connect handlers remain.
Tried it on OS X, Ubuntu and Windows 7. Need to talk to Richard regarding easier setup in OS X. The main issue I am facing is whether to use Apple's Python or Python.org python.
Presently looking into :
12 Jun 2011
Some work on replacing libglade with Gtk Builder in the PyGTK GUI changeset 3483.
14 May 2011
After a discussion with John, the more important bugs to be fixed are
- bug 423 Changing value of solved variable should force removal of 'solved' indication
- bug 501 pygtk/ascdev fails to load solvers under Windows 7
- bug 507 propagate var/relation 'solved' status up through model hierarchy in processVarStatus
- bug 429 default units often not very useful
- bug 472 slvreq: with SOLVER statement before FIX/FREE methods, model is not updated
- bug 294 Implement 'STUDY' function in PyGTK GUI








