GUI - progress - unify into single window

[GoogleCodeExporter]

The GUI's progress dialogues are currently implemented as separate windows, 
called as needed.  

The issue is that these often overplot each other, and can be difficult for the 
user to separate when one comes in and out of existence rapidly.  

It should simplify the user experience by having a single progress window with 
a vbox that is shown/hidden as needed.  Each individual progress dialogue can 
then have its own vbox slot and be shown/updated/destroyed as needed.

Original issue reported on code.google.com by shawnlaffan on 9 Jun 2012 at 12:40

[GoogleCodeExporter]

Push back to later release

Original comment by shawnlaffan on 4 Jul 2012 at 10:35

• Added labels: ****
• Removed labels: Milestone-Release0.17

[GoogleCodeExporter]

Original comment by shawnlaffan on 10 Aug 2012 at 12:27

• Changed title: GUI - progress - unify into single window
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r1109.

Initial work.  Most certainly does not work yet.  

Original comment by shawnlaffan on 23 Aug 2012 at 11:25

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Developments in issue #5 have relevance here.

See also this signal handler:
https://developer.gnome.org/gtk2/2.24/GtkWidget.html#gtk-widget-hide-on-delete

Original comment by shawnlaffan on 16 Jul 2013 at 12:45

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r1694.

New branch to work on unifying the progress bars. 

Original comment by shawnlaffan on 18 Jul 2013 at 9:55

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r1695.

Delete the old branch.

Original comment by shawnlaffan on 18 Jul 2013 at 9:58

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r1696.

It seems to work so long as the window is not closed while it is running.

Original comment by shawnlaffan on 18 Jul 2013 at 11:37

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r1697.

More fiddling.  Probably need to put the window into its own package with a 
singleton, and then register the progress dialogs with the singleton.  That 
would simplify the construction and destruction of the widgets and avoid double 
destruction.  

Original comment by shawnlaffan on 18 Jul 2013 at 12:19

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Add target milestone

Original comment by shawnlaffan on 31 Oct 2013 at 1:58

• Added labels: Milestone-Release1.0
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r2152.


adding methods to handle common progress bar window.  it shows multiple 
progress bars active in an extended vbox, and removes each as use of the 
progress object finishes.  this makes use of the existing ProgressDialog object 
and interface, so no change is needed to calling methods.

it may need changes eg for methods such as randomisation, where multiple very 
short progress instances are called.  the progress dialog appears and 
disappears quickly as each is brought up and removed in succession, its not 
clear what the preferred behaviour is, perhaps changes to the display of 
progress in these instances could be used.  a possible alternative change is to 
maintain completed entries, in a scrolling window with new entries at top.

Original comment by anthony....@gmail.com on 25 Feb 2014 at 8:13

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r2154.

Add a warning when the GUI progress cannot be created.  Could be a croaker.
Add progress bar to the randomisation.  It never actually had one before...
The rest is just neatness.  

Original comment by shawnlaffan on 25 Feb 2014 at 9:55

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Original comment by shawnlaffan on 25 Feb 2014 at 9:55

• Changed state: Started
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r2155.


Handling display of progress dialogs, eg catching when the window is closed, 
and keeping track of all relevant dialogs attached to progress.  It handles the 
basic case, but there seem to be issues eg after closing a progress window the 
behaviour is different when run a second time.  Also often display of first 
progress (eg "1 of 101 this run") doesn't show, not clear why.

Original comment by anthony....@gmail.com on 26 Feb 2014 at 8:20

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r2156.

Progress bars: Set the last update time back by twice the update interval when 
the object is created.

Original comment by shawnlaffan on 27 Feb 2014 at 3:38

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r2157.


fixed issue with display of progress not updating first display, as a result of 
time interval test preventing update of labels

fix issue with progress window not displaying after window is closed.  changed 
so window is allowed to be destroyed, $self->progress_bars is cleared, all 
progress dialogs are removed and a new init call is used when progress is next 
called.

Original comment by anthony....@gmail.com on 27 Feb 2014 at 4:39

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r2236.

Minor style changes.  

Original comment by shawnlaffan on 24 Mar 2014 at 3:27

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Remaining issues having tested using a long randomisation process:
1.  Make the frames take up only as much space as they need.  This should just 
be a frame packing property.
2.  Avoid the progress window grabbing the window manager focus every time a 
new progress dialogue is added (tested on Windows, not sure about Linux).  The 
effect is to make working in some other application impossible until the 
Biodiverse process has finished.  This has been a problem as long as we have 
had progress bars in the system.  

Original comment by shawnlaffan on 24 Mar 2014 at 3:30

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r2237.

Stop presenting the progress window each time a new progress bar is added.  The 
show_all seems to do the trick.  
Possibly we should ->present when the window is first instantiated, but this 
appears to happen by default anyway.  

Original comment by shawnlaffan on 24 Mar 2014 at 3:41

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was updated by revision r2238.

Pack the vbox using heterogeneous spacing.
A small amount of refactoring for readability (fewer hash lookups).

Original comment by shawnlaffan on 24 Mar 2014 at 3:55

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue can be closed when the branch for issue_408 is merged across to the 
trunk.

Original comment by shawnlaffan on 24 Mar 2014 at 4:49

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This issue was fixed by revision r2255 (merger of the issue 408 branch across 
to the trunk)

Original comment by shawnlaffan on 27 Mar 2014 at 1:18

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****