[Kstars-devel] branches/work/kdeedu_kstars_htm/kstars/kstars

[James Bowlin]

On Sat August 11 2007 5:32 am, Thomas Kabelmann wrote:
> By the way, in the long term we should convert other classes like
> KStarsData, KSNumbers (?)  into a singleton. There is always only 1
> instance at runtime and we mess up method signatures with pointers to
> these classes.

I think this is great idea for KStarsData.  I'm still confused by 
KSNumbers.  It is used in StarObject::updateCoords() but only for
the KStarsDateTime it contains (I think).  So in my code I ended
up slinging around KSNumbers objects (which seemed wasteful) instead
of KStarsDateTime.   Also, FYI, I gave KStarsData at least one
KSNumbers data member that allowed me to bypass the chain of 
update( KStarsData, KSNumbers ) calls and implement just-in-time
updating inside the draw loops of everything that uses the index.
The chain of update() calls still exists because not everything
is in the index.

I will have an ongoing need to have some stars with high proper
motion indexed at a different time than the bulk of the stars.
The high PM stars get re-indexed faster so all the stars are always
within 25 arcseconds of the screen aperture.  I'm storing the index
times as KSNumbers but it would be better to switch them all to
KStarsDateTime as long as that won't break anything.

Is there a simple rule for when KSNumbers is needed versus when
a KStarsDateTime will suffice?

Also, I'm curious why we make two instances of KStarsData, one in 
main.cpp and another in kstars.cpp.  Are both being used?

-- 
Peace, James