[Kstars-devel] AuxData and QStrings in unnamed star objects

[Akarsh Simha]

> Interesting question is how construct unique hash for sky objects. I could not 
> imagine one. And in this case there is no need to store AuxData in SkyObject 
> it always could be retrieved from hash.

For dynamically loaded stars, this is fairly easy. They all live on a
Triangular Mesh of depth 8. So first, we can identify the "trixel" by
a number (< 4 * 4^8, or something like that). Once the trixel is
identified, the stars in the data file are placed in order in each
trixel. Just having their "line number" within each trixel appended to
the trixel number should produce a UID.

But I have always wanted to have a UUID for every object in
KStars. This might be hard stuff, but it would be nice if every object
carried a few bytes of its own UUID. Maybe it's not required - except
for unnamed stars - where it will be rather useful to have a UID, or
even a legitimate catalog number attached.

BTW, one thing I don't like is the findByName("Sun") or
findByName("Moon") or findByName("Jupiter") calls used to get pointers
to the sun / moon / Jupiter when required. We can't make the sun and
the moon singletons (they are copied in several places). I think it
would make sense to have a place that stores pointers to objects like
these, which are used throughout KStars.

> > Also, one way to deal with the QStrings in unnamed star objects is to
> > make sure we use pointers to QStrings instead of QString objects or
> > references.  Then we don't have to worry about freeing QStrings inside
> > of unnamed stars.  I think (but I'm not at all sure) that this might
> > also work for references.  I *think* that references are internally
> > (to C++) just like pointers.  So if all of the unnamed stars are
> > referencing the same QStrings, then again we don't have to worry about
> > freeing QStrings when deleting unnamed stars.  In fact we might have
> > relied on a trick like this.  It is possible that the QStrings are okay
> > (although ugly) and the only thing that needs to be fixed is AuxInfo.
> > Although if this is the case, we certainly need to comment the code to
> > explain what is going on.
> >
> References are actually pointers in disguise.
> 
> Another approach is to store all proper names (like Dumbell nebula) in some 
> kind of global hash same way as AuxData. It's possible because number of such 
> names is limited. This way names need not to be stored in SkyObject.
> And catalog names like M33, NGC224, HD44444 could be generated on the fly.

Hmm... sounds like a good idea to me. 

[I'll take a look at this mail in detail later. Gotta leave now]

Regards
Akarsh