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

[James Bowlin]

On Thu August 2 2007 6:42 pm, Jason Harris wrote:
> Excellent.  Can the re-indexing be performed in the background while
> the UI remains responsive?

I'll think about it.  My gut feeling is to put this off until 4.2
or 4.3. I think a little splash screen might be appropriate explaining
what is going on.  It would be easy for me to update it with the 
percentage completed.  I don't think a 4 second wait to get a very
fast UI is terrible.  I think I can do just what you want but I want
to wait until we know what I've done so far is rock steady first.

If you think this is important, I can start working on it next if
you want.

> Regarding the constellation boundaries: believe it or not, we
> actually should not precess them.  They were defined by the IAU in
> the 1930s to divide the sky into 88 regions, but the vertices of
> these lines are fixed RA/Dec values. They were actually drawn up
> using epoch 1875.0, so there are already significant offsets (for
> example, the southern border of Canis Minor is just below the
> equator, and is not quite parallel to it).

Great!  One less ugly thing to do.

> > I also need to re-index the constellation lines every 150 years
> > just like I do for the stars because stars form the vertices of the
> > constellation lines.  To do this the right way I will have to
> > change the data members that hold the index in LineListIndex into
> > pointers (instead of simply values).  I'll probably do this
> > tomorrow.
>
> It would probably make more sense to modify
> ConstellationLineComponent so that it stores a QList of pointers to
> the star objects themselves, rather than creating its own copies of
> these points.  I can try to take care of this if you agree it's a
> good idea.

This is what baffles me.  I don't make a copy, I put a pointer to the 
star itself into the ConstellationLines LineLists:

SkyObject *star = data->skyComposite()->findStarByGenetiveName( name );
if ( star && lineList ) {
    lineList->points()->append( star );
}

I rewrote FindStarByGenetiveName to use a hash to make the lookup fast
so I'm certain there is no copying going on.  I had originally used
a copy but that quickly broke badly as time advanced.  This is a
different problem because the stars just jump a little and then the
lines eventually catch up.  Is it possible that a StarObject will 
occasionally return different (ra, dec) values depending on whether
it is cast as a SkyPoint or a StarObject?  This seems unlikely.

But I still need to re-index the constellation lines just like the
stars because the stars are at new locations in the index due to
proper motion.


-- 
Peace, James