[Kstars-devel] Questions about planet skycomponents

[kstars@30doradus.org]

Hello,

> I think the drawTrail() function belongs in the KSPlanet/KSAsteroid/etc 
> class, rather than in the Component.  In KStarsData, we will keep a 
> QList of pointers to all the solar system bodies that have trails attached, 
> so it makes more sense to have the drawing function attached to those 
> objects.

Sorry, disregard this.  drawTrail() does belong in the Component
classes.
In fact, I moved drawTrail() into the parent class 
(AbstractPlanetComponent), and it does not need to be redefined in any 
subclasses.  

The issue remains, do we want to keep track of which objects have a
trail?
We could just implement a function SolarSystemComposite::drawTrails(), 
which calls drawTrail() on all solar system bodies.  This is actually
how 
we did it in KDE-3.x.  However, this brute-force loop over all SS bodies

seems wasteful, considering that the vast majority of bodies will not
have 
a trail.  It would be better if we kept a list of pointers to the SS
bodies that 
have a trail, and just loop over the objects with trails, if any.

The problem is, where to put this list?  We could put it in KStarsData,
and make the function SolarSystemComposite::drawTrails() loop over
data->trailPlanetsList to draw the trails.  Unfortunately, this totally
breaks
the mold of how Composite/Components are supposed to work.  

An alternative that would be more aligned with the Components design 
would be for AsteroidsComponent and CometsComponent to each keep 
their own trailList.  That way, SolarSystemComposite::drawTrails() can 
just call drawTrail() on each of its children, blissfully ignorant of
who has 
a trail.  However, we're still breaking the mold a bit, because we'd
need to 
add public append/remove functions to AsteroidComponent and 
CometComponent, so the user can add/remove trails.  Either that, or 
these Components' update() functions could rebuild the trailList,
checking 
each asteroid/comet for a nonzero number of trail points.  It's looping 
through all of the objects anyway, so this isn't such a big performance
hit.

It's too bad we can't just put the trail-drawing code in the draw()
function, 
since this needs to be called on each object.  However, I don't do it
that 
way because I want all of the trails to be drawn first, before any of
the 
actual bodies are rendered, to guarantee that they are in the back.

Any thoughts?

Jason