[Kstars-devel] Questions about planet skycomponents

[Jason Harris]

Hello,

This is mostly directed at Thomas, but I think the list will be interested in 
the discussion.

I'm trying to work on the skycomponents directory, but I'm not clear on how to 
proceed with the solar-system components.  Here's my take on the set of 
components we'll need to complete the solar system:

SolarSystemComposite [exists]: container for all solar system components

AbstractPlanetComponent [exists]: base class for all other solar-system comps
PlanetComponent [does not exist]
SunComponent [does not exist]
MoonComponent [does not exist]
PlutoComponent [does not exist]
AsteroidsComponent [exists]: list of KSAsteroid objects
CometsComponent [does not exist]: list of KSComet objects

------
One thing that isn't clear to me: most of the Component classes contain a 
QList of objects of a given type, but now we have a few components with only 
one member (like SunComponent and MoonComponent).  I don't understand what 
the separation will be between these component classes and the existing 
SkyObject classes (KSSun and KSMoon).  I mean, is the point to get rid of 
KSSun and KSMoon, and put all of that code in SunComponent and MoonComponent, 
or is there some logical way to determine what goes in the component, and 
what stays in the SkyObject class?

I guess one way to answer the question is that the components don't get much 
of the KSSun/KSMoon/KSPluto/KSPlanet code at all, and that these classes are 
restricted to the code we used to have in KStarsData (loading data from 
files; updating positions) and SkyMap (drawing to the screen).  Is that about 
right?

On a similar note, will PlanetComponent contain a QList of all planets (except 
Pluto), or will we have a separate instance of PlanetComponent for each 
planet?  From your preliminary work in solarsystemcomposite.cpp, I guess you 
intend the latter.

thanks,
Jason
-- 
KStars: KDE Planetarium
http://edu.kde.org/kstars