[Kstars-devel] Questions about planet skycomponents

Thomas Kabelmann thomas.kabelmann at gmx.de
Sun Sep 25 16:53:02 CEST 2005


Hello Jason,

first of all I will answer you from memory, as my hard disc drive crashed 2 
days ago and I will try to set up a new system tomorrow. So there might be 
some mistakes talking about KSSun etc.

> 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?
My approach is to have an unified interface for all sky objects (even horizon 
an so on). So there are 2 ways to do this. First we could implement all code 
update/init/draw in a separate class like currently done in the components or 
we could put this code in existing classes like SkyObject, KSPlanet... But 
this would blow up the code in the existing classes. A second issue for 
instance would be, how do we init a SkyObject. We could have a list of 
SkyObjects and read from a file and in a second case we only have 1 SkyObject 
and read from a different file. So we have 2 different ways of init but all 
calculations of SkyObject are the same.

I prefer the first way, because we should separate the astronomical 
calculations from the representation, initialization and updating the data. 

> 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?
Yes, that's 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.
I'm always trying to have as less as possible code, so I will write only 1 
PlanetComponent. Since all planets share the same code I would have a 
separate instance of PlanetComponent for each planet. My problem was, how do 
we know, if the planet is visible (Options::showMercury() etc.) This I solved 
by using a function pointer to the corresponding option method. So we will 
have a generic method for checking visibility and can do it this way:

PlanetComponent::draw()
{
	if (visible()) // visible() returns a pointer to Options::showPlanet()
		ksplanet->draw();
}

I hope this clarifies some questions you have.

Regards,
Thomas


More information about the Kstars-devel mailing list