[Kstars-devel] RFC: Redesing of KStars

[Jason Harris]

Hi Thomas,

This sounds very reasonable.  It seems like "SkyComponent" will replace (and 
extend) "SkyObject".  Why not keep the name "SkyObject"?  We'll probably also 
need to subclass "SkyComponent" in the same way that SkyObject is subclassed 
for different kinds of objects (because different objects draw themselves 
differently, for example).  I'd also suggest renaming "SkyComposite" to 
"SkyObjectGroup" or something similar.  Those names just seem more intuitive 
to me.

Jason

On Tuesday 02 August 2005 09:50 am, Thomas Kabelmann wrote:
> Hi Jason,
>
> > I imagine there will be quite a few problems with libkdeedu, especially
> > extdate (which is basically a hacked version of QDateTime and friends).
> > Q_EXPORT is just a macro that was defined in Qt-3.x, to indicate that the
> > function should be exported.  Try changing them to KDE_EXPORT maybe?
>
> seems to compile with KDE_EXPORT, but there are a lot of other compile
> errors too, so I will have a look at QT4 porting guide and try to change
> them.
>
> I have refined the design of my approach to refactor the skymap and data
> classes. I will use the composite design pattern, so we can organize the
> sky recursively.
>
> We will have 2 abstract classes - SkyComponent and SkyComposite. A
> SkyComponent is a simple object which knows, how to draw, update and init
> (init will data from files too) itself, for example the equator. A
> SkyComposite is a complex object like solar system, which is composited by
> other components or composites and delegates draw/update/init to it's
> components. It could be also possible that Composite is initializing it's
> components by itself. This is useful for the StarComposite (currently
> starList), because it would make no sense having a data file for each star,
> but this are imlemenation details.
>
> The components of a composite will be added in the constructor. The solar
> system could look like this:
>
> SolarSystem::SolarSystem()
> {
> 	add(new Sun());
> 	add(new Merkur());
> 	...
> 	add(new Pluto());
> }
>
> A draw of a composite would look like this:
> SkyComposite::draw(Skymap *map)
> {
> 	foreach (component in components) // components is a list of components
> 		component->draw(map);
> }
>
> With this design, we just add a SkyMapComposite as member to the KStars
> class, which will recursively add new components/composites. An object
> hierarchy would look like this:
>
> - SkyMapComposite
> 	- SolarSystemComposite
> 		- Sun
> 		...
> 		- Merkur
> 	- StarComposite
> 		- a lot of stars
> 	- DeepSkyObjectComposite
> 		a lot of objects
> 	- equator
> 	...
> 	- horizon
>
> We just have to say skyMapComponent->update()/draw()/init() and all objects
> do it at once.
>
> For further explanation I've appended a class diagram for the redesign. If
> there are any questions, please feel free to ask me. If the explanation was
> to short I would write a design paper, too.
>
> 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