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

[Jason Harris]

Hello,

On Tue, Jun 3, 2008 at 8:04 PM, James Bowlin <bowlin at mindspring.com> wrote:
> Yes, A QString could be a problem.  When you said "string" I though you
> meant char[size].  Those QStrings are a big PITA.  Ideally, we could
> store the SpType as a char[size] in the StarObject and then do any
> internationalization or translation when we are actually outputting the
> data to the screen (assuming this is a very infrequent event).
>
The Spectral type string is a code, so it doesn't need to be
translated anyway.  It could easily be stored as a char[size].

> The other QString and QStringList members of SkyObject are more of a
> problem.  If all of these fields will be required for unnamed stars
> then we will have to take evasive action.
>
I don't think *any* of these are required for unnamed
stars...especially at the beginning of this project, I think Akarsh
should regard these fields as being needed for named stars only.

As I said in a previous message, one idea is to store these strings in
a separate hash, indexed by the name of the star.  Eventually, if we
want to enable these strings for unnamed stars, we can allow indexing
by the HD number or our own UID.  The number of objects with userlog
data is probably going to be very small for most users.  The number of
links may be a bigger issue, since by default you get several dozen
image and info links.  Still, I don't think it would be a performance
issue until there were thousands of links, and even then it doesn't
matter too much, because the hash would only need to be searched when
showing the popup menu or details window.  We could play tricks with
caching and preloading prominent on-screen objects if we wanted to
speed things up.  But that's for far in the future, I think.

> There is probably more work you can do for now, but we really need to
> find out ASAP from Jason what he wants to do with the QString and
> QStringList SkyObject fields in the dynamically loaded unnamed stars.
>
Unless either of you has a criticism, I like my QHash idea.  However,
if Akarsh doesn't want to be distracted by this issue at all, I see no
problem in disabling user-logs and image/info links *entirely* for
*all* stars, for the time being.  Of course, the data members would
have to be moved out of SkyObject and into the child classes that need
them (KSPlanetBase and DeepSkyObject), which is a little hacky, but
not too bad.

Then we could work out a QHash solution later.

> I wonder if we might want to create an UnnamedStar class that subclasses
> directly from SkyPoint and bypasses SkyObject.
>
Interesting idea, but it might lead to problems, for example if the
user attempts to click or right-click on an unnamed star...

regards,
Jason