[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