TimeController widget - default time

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Do not use autoupdate option for a data item in project (i.e. leave 
override master time equal true)
2. Set some start time (or don't)
3.

What is the expected output? What do you see instead?
Widget has some time that doesn't have any correspondence to anything 
(where is this default coming from?)

Original issue reported on code.google.com by mike.bot...@gtempaccount.com on 20 Oct 2008 at 10:06

[GoogleCodeExporter]

If you do not set <baseTime> AND do not use autoUpdate attribute for a 
dataItem, its
baseTime defaults to the current System time.  
If you do set a <baseTime> and do not use autoUpdate attribute, the baseTime you
specify should appear in the "Override Time Control" text area for that 
dataItem. 
Currently, it still initializes with the current System time.  This is a bug.  
I will
fix it.  

Original comment by TheRest...@gmail.com on 21 Oct 2008 at 8:51

[GoogleCodeExporter]

Bug was corrected in org.vast.stt.gui.widgets.time.MasterTimeWidget.  Fix 
committed
to SVN repo 10/21.

TC

Original comment by TheRest...@gmail.com on 22 Oct 2008 at 12:21

• Changed state: Fixed

[GoogleCodeExporter]

One additional note.  Now, if you specify a <TimeExtent> with no <baseTime> in 
the
Proj file, the "Override Master Time" text area will show "Jan 1, 1970", which
reflects the value of 0.0 for baseTime in the associated TimeExtent object.  If 
you
want to default to System time instead, or perhaps SceneTime, this should be 
done in
org.vast.stt.provider.ExtentReader, when the TimeExtent is initialized.  I put
comments in the code to that effect.  IMO, you should always include <baseTime> 
in
the <timeExtent> in STT project files.  That makes the intent unambiguous.

TC

Original comment by TheRest...@gmail.com on 22 Oct 2008 at 12:30

[GoogleCodeExporter]

One final (hopefully) quirk to be resolved with TimeExtent's behavior when 
items are
created from Project file.  If timeExtent is set to autoUpdate to scene's time, 
the
specified <baseTime> in that extent gets lost.  I.e.:

 <name>KESX Doppler SOS</name>
 <timeExtent autoUpdate="#SCENE_01">
   <TimeExtent>
     <baseTime>1956-12-24T11:59:59</baseTime>
     <lagTime>0</lagTime>
     <leadTime>300</leadTime>
     <stepTime>0</stepTime>
   </TimeExtent>
 </timeExtent>

Upon instantion, the associated TimeExtent object briefly has the baseTime from 
the
Project snippet above.  Then, it is assigned a SceneTimeUpdater b/c of the 
autoUpdate
attribute.  This updater wipes out its baseTime.  Also, every time you toggle
'Override Master Time' ON, the Text Widget in the Override control gets reset 
to the
Scene's time.  Definitely not the desired behavior.

I need to do a little debugging to figure out the best way to fix it.

TC

Original comment by TheRest...@gmail.com on 22 Oct 2008 at 1:17

• Changed state: Started

[GoogleCodeExporter]

That last problem definitely happens because there is only base time in the
TimeExtent object and no place to save the old one when the SceneTimeUpdater is 
engaged. 

It seems that just adding a new defaultBaseTime attribute to TimeExtent would 
be a
hack since it's usually not applicable... I think the best way would be to take 
care
of it from outside. Perhaps the GUI and the reader should be responsible for 
dealing
with this case in the project file...

Original comment by i...@sensiasoftware.com on 24 Oct 2008 at 2:15

[GoogleCodeExporter]

A simple fix would be to add defaultBaseTime to STTTimeExtent.  STTTimeExtent 
extends
TimeExtent to add listeners and an updater.  Adding a 'defaultBaseTime' there 
doesn't
seem a hack b/c it is STT-specific anyway.  A second solution would be to add a
'DefaultTimeUpdater', which gets a little more involved (but still quite 
doable).  I
will take the first approach initially.

T

Original comment by TheRest...@gmail.com on 24 Oct 2008 at 3:17

[GoogleCodeExporter]

Made the fix discussed in Commen #6.  Code was updated in SVN for
stt.gui.widgets.time.TimeExtentContorller and stt.provider.ExtentReader.  Fix 
seems
to work with initial testing.  May need to revisit when we implement 
RealtimeUpdater
stuff.

T

Original comment by TheRest...@gmail.com on 24 Oct 2008 at 4:04

[GoogleCodeExporter]

I think we could take a more general approach to solve this. Something like 
this can
happen with any object for which we want to update some attributes 
automatically, but
still want to save default values specified manually, so that we can revert to 
it
when the auto update is deactivated.

So I think another solution would be that the updater is responsible for
saving/restoring the state of the object when it is engaged/disengaged

What do you think?

Original comment by i...@sensiasoftware.com on 24 Oct 2008 at 8:53

[GoogleCodeExporter]

Followup to Comment #7: you also need to check out stt.provider.STTTimeExtent.  
I
forgot to check that one in earlier, but it is there now.  

For Comment #8, do you mean something that we can use throughout the code, or
something specific to the updaters and time options?  I think for the time 
stuff,
there is not much in the way of options to store other than that baseTime.  The
SceneUpdater only works on baseTime currently RealtimeUpdater might add 
something,
but not sure of that.  

Java Properties is a nice object for storing simple parameters if we decide to 
go
that way.  Some of this might fall out, too, when we finish the ProjectWriter
(something we need to do soon :>).  

Original comment by TheRest...@gmail.com on 25 Oct 2008 at 1:29