Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
mike.bot...@gtempaccount.com
on 20 Oct 2008 at 10:06