[Kstars-devel] Questions about planet skycomponents
Jason Harris
kstars at 30doradus.org
Tue Sep 27 03:16:13 CEST 2005
Hello,
On Monday 26 September 2005 01:18 pm, Thomas Kabelmann wrote:
> SkyMap::clickedComponent() {
> return ClickedComponent;
> }
>
> SkyMap::clickedObject() {
> return clickedComponent()->ActiveElement();
> }
>
Ugh, I don't like this at all. What about the other times we need to get an
object pointer, such as focusObject() or transientObject()?
Are we going to have clickedComponent()->clickedObject(),
focusComponent()->focusObject(), and transientComponent()->transientObject()?
If we do it this way, each Component would have its own ClickedObject,
FocusObject, and TransientObject. There should only be one of each. I know
that the "clickedComponent()" functions discriminate between them, but that's
very messy and non-intuitive.
I think SkyMap::objectNearest(SkyPoint *p) needs to traverse all of the lists
stored in the Components (something SkyComposite can presumably do), and
simply return the pointer to the SkyObject nearest p. We don't need to know
what Component it is in.
> Another way could be adding virtual function add/removeTrail() to the
> SkyComponent like your approach. Then we need new abstract components like
> ListTrailableComponent and TrailableComponent, which are overriding the
> default implementation. AsteroidsComponent is then derived from
> ListTrailableComponent.
>
I agree with this approach.
Some code examples to illustrate what I am thinking:
---Finding the nearest object:-----------------
SkyObject* SkyMap::objectNearest( SkyPoint *p ) {
return skyComposite()->findObjectNearest( p );
}
//This is probably over-simplified. In the current version, we do all
//kinds of fancy trickery to make sure that some types of objects are
//more easily selected than others. We probably want to keep this hierarchy.
SkyObject* SkyComposite::findObjectNearest( SkyPoint *p ) {
SkyObject *nearest=0;
foreach ( SkyComponent *comp, components() ) {
SkyObject *try = comp->findObjectNearest( p );
if ( try ) {
if ( ! nearest ) nearest = try;
else if ( try->angularDistanceTo(p)
< nearest->angularDistanceTo(p) )
nearest = try;
}
}
return nearest;
}
---Finding an object by name:---------------------
SkyObject* KStarsData::objectNamed( const QString &name ) {
skyComposite()->findByName( name );
}
SkyObject* SkyComposite::findByName( const QString &name ) {
SkyObject *o = 0;
foreach ( SkyComponent *comp, components() ) {
o = comp->findByName(name);
if ( o ) return o;
}
return 0;
}
//Using the abstract parent classes as Thomas suggested, named
//ListComponent and SingleComponent
SkyObject* ListComponent::findByName( const QString &name ) {
SkyObject *o = 0;
foreach( SkyObject *o, internalList() ) {
if ( o->name() == name ) return o;
}
return 0;
}
SkyObject* SingleComponent::findByName( const QString &name ) {
if ( member()->name() == name ) return member();
}
---Attaching/Removing a Trail:----------------------
(The actual Trail management is done as we do now, in SkyMap and KSPlanetBase.
The only difference: KSPB::addToTrail() and KSPB::clearTrail() send Signals to
SolarSystemComposite, which contain a pointer to the object which has
added/removed a trail)
//This way does not use the trick of checking the object's type to
//determine the Component
void SolarSystemComposite::slotAddTrail(SkyObject *o) {
foreach ( SkyComponent *comp, components() ) {
bool result = comp->addTrail(o);
if ( result ) return; //stop when object found
}
}
//Example of a "list-type" component, using an abstract parent class
//as suggested by Thomas to reduce duplicated code
bool ListComponent::addTrail(SkyObject *o) {
foreach ( SkyObject *a, internalList() ) {
if ( a == o ) trailList.append(o);
return true;
}
return false;
}
//Example of a "single-member" type component, using an abstract
//parent class as suggested by Thomas to reduce duplicated code
bool SingleComponent::addTrail(SkyObject *o) {
if ( member() == o ) {
HasTrail = true;
return true;
} else {
return false;
}
}
Jason
--
-------------------------------
KStars: KDE Desktop Planetarium
http://edu.kde.org/kstars
More information about the Kstars-devel
mailing list