[Kstars-devel] Questions about planet skycomponents

[Jason Harris]

Hi Thomas,

On Monday 26 September 2005 11:36 am, Thomas Kabelmann wrote:
> without having a look in the code, I understand the problem of adding a
> trail as following. We get a SkyPoint from the SkyMap and are now searching
> for a corresponding SkyObject. So we have to traverse through appropriate
> SkyComponents to find the SkyObject. Now if we have found the SkyObject, we
> know the component too and can easily add this SkyObject to the trail list
> of the component.
>
No, the Signal sends a pointer to the SkyObject itself which has added|removed 
a trail, not the SkyPoint of the trail.  So the Slot will have the SkyObject, 
and can use the object's type (ASTEROID, COMET, PLANET) to determine which 
child owns that object (in the case of PLANETs, it will also need the 
object's name).  There's no need to search through the Components.

> So I agree with you, that the trail data don't belong into the component.
> But I would prefer the Trailable class, because it encapsulates the
> functionality of adding/removing trails to components (just the sky objects
> which have trails, not the trails itself). It would be a slight but not
> measurable overhead for objects, which are standalone components unlike
> asteroids, but I would always prefer a simple and generic solution. And we
> can also put planets in composites like InnerPlanets/OuterPlanets and these
> composites know which planets have a trail.
>

It seems to me that with the Trailable class does not solve the problem of 
notification.  When SkyMap or KStars add or remove a Trail, how does the 
Component find out about it?  I think my proposal is simpler than having 
multiple inheritance of an additional class, but maybe I don't fully 
understand.  From the point of view of the API, my proposal is also generic 
for all AbstractPlanetComponents.  They all have public functions 
addTrail(SkyObject*) and removeTrail(SkyObject*), which get called from the 
slots in SolarSystemComponent described in my prev. message.  The difference 
is in the implementation:  CometsComp and AsteroidsComp add/remove the object 
from their private QLists of trailed objects, and the other classes simply 
set a private bool member (HasTrail) true/false.  That's pretty simple, isn't 
it?

> > Issues:
> > SolarSystemComposite would have to be made a QObject, and would have a
> > moc file.
>
> Should be no problem if we need this functionality.
>
Okay.

> > Is it desireable/possible to have a solarsystemComposite pointer that is
> > visible to SkyMap and KStarsData ?
>
> For performance reasons we could do this so, but it's not really nice :-)
>
We'd definitely need this to do a Signal/Slot notification.

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