[Kstars-devel] Binary star data loading accomplished in Branch!

[James Bowlin]

On Tue June 3 2008, Akarsh Simha wrote:
> How about we inherit two classes, PlainStar and NamedStar from
> StarObject and implement these init functions in them differently?

That is not a good idea IMO.  StarObject already contains pointers for
the name fields.  When you create a subclass you can't take fields away,
you can only add fields.  IMO the best solution would be to convert 
StarObject to PlainStar and remove the name data fields.  There would
be virtual functions that return for name() and gname() that just return
the translation of "star".  There might also be a virtual hasName() 
function.

Then NamedStar would subclass from PlainStar and add back the two name
fields and override the 3 virtual functions.

This was part of my original proposal.  I think it should be done 
someday but I think it might take a lot of work and would be a 
distraction from the main event (of extending the catalog).  That part 
of the KStars code base seems messy to me (but maybe that is just 
because I'm not familiar with it).  Part of the problem is that the
name fields are part of SkyObject so PlainStar can't inherit from
SkyObject but NamedStar wants to.

Anyway, since there already must be code to initialize named stars 
slightly differently than unnamed stars, I don't see what the big deal 
is.  It seems that you are worried a lot about a few lines of nearly 
duplicated code.

The named stars are an exception and as such they are a slight PITA as
far as the extended catalog is concerned.  To be honest, I don't have
a perfect solution for dealing with them.  I think we may end up having
to have the named stars kept in their own little list that gets drawn
separately from the unnamed stars.   This may cause a much larger 
problem with nearly duplicated code, which might be "solved" by 
replacing the StarComponent class with PlainStarComponent and 
NamedStarComponent classes.

One problem we face is that my idea of promoting dim named stars to the
global stars group was a bad idea because it breaks the simple idea
of ending the draw loop as soon as we get a star dimmer than a threshold
magnitude.

We also face a difficulty that my simple idea of duplicating some
high PM stars to account for proper motion probably won't work for named 
stars. Maybe it would be okay but I forsee possible difficulties.

Right now, I'm leaning toward keeping the named stars in their own list 
(StarIndex structure) that gets drawn separately from the rest of the 
stars.  The named stars would get treated the way we are currently 
treating all the stars.  They would even have HighPMStarLists and if 
necessary, we could re-index all the named stars.

I would hate to have *three* different lists/structures of stars that 
need to be drawn, so if the named stars are in their own list then I 
would like to put the global stars and the dynamically loaded stars in 
the same list/structure.  This shouldn't be very hard if we have
variable sized StarBlocks.  To draw the dynamic stars we were planning
on having an array of StarBlockLists indexed by trixel so all the 
dynamic stars in trixel 17 would in the StarBlockList at:

  dynamicStarIndex[17]

(or whatever we call the top data structure).

The global stars would then simply be in the first StarBlock in every
StarBlockList.  Those first StarBlocks would always stay put, they 
wouldn't get re-used like the StarBlocks for the dynamically loaded 
stars.  They would typically be smaller than the StarBlocks used for
the dynamic stars, but this is okay because we are not planning to 
re-use them.

A more elegant solution might exist, but this is the best I've been able
to come up with so far.  The key point is I am now agreeing with an idea
you originally proposed, which is to have the named stars in an entirely 
different list from the unnamed stars.  This means I am totally okay 
with having the named stars in their own data file (separate from the 
global stars) if this makes the initialization code simpler for you.

For example, one way to move forward is to leave your existing binary 
initialization code more or less as it is but only use it for named 
stars.  Then start afresh with code for loading the (unnamed) global 
stars into StarBlocks.  If you would prefer to keep the named stars
in same file as the unnamed global stars, that is fine with me too.

I'm sorry if this seems to pull the rug out from under your feet a
little.  In my defense: 1) this was supposed to be my week off so I 
haven't been concentrating on the extended catalog as much as I might 
have otherwise, and 2) you have made much more rapid progress than I
had anticipated.


-- 
Peace, James