[Kstars-devel] Questions about planet skycomponents

[Jason Harris]

A Trailable class is an interesting solution.  However, only 
AsteroidsComponent and CometsComponent will actually contain more than one 
object; each of the other components will contain only one member.  So, while 
subclassing from Trailable would work, it isn't a great fit for these 
single-member components.

Here's another idea: the trails themselves, the actual list of SkyPoints, is 
stored in KSPlanetBase, and trails are added, removed and updated by the 
KSPlanetBase functions addToTrail(), clearTrail(), and updateTrail().  This 
is where they belong; all the Components need to know is whether their 
member(s) have a trail.  So we could have addToTrail() and clearTrail() send 
SIGNALs that the object now (has | does not have) a trail, which are caught 
by a SLOT in SolarSystemComposite, and distributed to the appropriate child.
Now, since we do not want to connect a SLOT/SIGNAL for every solar system 
object, the SIGNAL should belong to KStarsData, and the KSPlanetBase 
functions can just use "emit data->addedTrail(o)".  The connection would look 
like:
    connect( data, SIGNAL(addedTrail(SkyObject*)), solarsysComposite, 
SLOT(slotAddTrail(SkyObject *o)) );
    connect( data, SIGNAL(removedTrail(SkyObject*)), solarsysComposite, 
SLOT(slotRemoveTrail(SkyObject *o)) );

and the slots would simply set a private bool HasTrail=true/false for 
single-member Components, or would add/remove the pointer argument from the 
private QList for AsteroidComp and CometComp.  The slots would would use the 
passed object's type (and name) to determine which child it belongs to.

Issues:
SolarSystemComposite would have to be made a QObject, and would have a moc 
file.

Is it desireable/possible to have a solarsystemComposite pointer that is 
visible to SkyMap and KStarsData ?

Jason

On Monday 26 September 2005 01:13 am, Thomas Kabelmann wrote:
> Hi Jason,
>
> for design reasons it would be the best that every component knows if it
> has a trail and draws itself. But I fully agree with you, that this is a
> big performance hit. Putting a list in KStarsData with all objects would
> mess up KStarsData. Your idea, putting a list to each component sounds
> reasonable. For this purpose I suggest to implement an own class Trailable
> and all classes which need this functionality can inherit it.
>
> Here is some pseudo code to sketch my idea:
> class Trailable {
> 	public:
> 		void addTrail(SkyObject *o) { trailObjects->append(o); }
> 		void removeTrail(SkyObject *o) { trailObjects->remove(o); }
> 		void drawTrails() {
> 			foreach (SkyObject *object; trailObjects)
> 				object->drawTrail();
> 		}
> 	private:
> 		QList<SkyObjects> *trailObjects;
> }
>
> So now every Component can inherit from Trailable and call drawTrails:
> class AsteroidComponent : SkyComponent, Trailable {
> 	public:
> 		void draw()
> 		{
> 			drawTrails();
> 			// draw asteroids
> 		}
> }
>
> Another issue, as you mentioned, is to find the skyobject. This is needed
> by adding trails too. Adding a generic find(SkyObject*) method is one
> possibility. But I personally prefer another way. I would like to add
> iterators to the component structure, so we could traverse all components.
> The big advantage is, that we can perform several actions on specific
> components and don't need to check all components. This is useful for
> operations, which are not included by all components, for example find().
> HorizonComponent doesn't need find() and we don't want to mess up the
> interface of the components. Currently I have no exact solution for this
> issue, but I'm evaluating 2 different approaches and will post my ideas
> soon.
>
> Thomas
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel

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