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

[Akarsh Simha]

Hi Jason

> 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.

Currently, the user-entered data doesn't seem to be stored between
restarts at all. It is probably important that we fix this in the
trunk for our 4.1 release, but this may end up breaking things when we
merge the branch later.

Since we are approaching release, if required, I could modify the code
in the trunk to work in the new way of dealing with these data and
port those changes into the branch as well.

I'd want your advice on this.

> Then we could work out a QHash solution later.

I'm okay with this too. Currently, this doesn't break my work at
all. We could even leave things the way they are and I could go on
with my work, unaffected. But it would probably be nice to see this
feature working correctly in KDE4.1, so we might want to work out a
solution for that.

> > 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...

I feel that it is best to keep the StarObject as a subclass of
SkyObject and adopt the solution with hashes.

That kind of an object hirearchy makes sense to me. We could hold all
the user entered data for Sky objects together in a hash and just pick
up whatever we want when we need it. This way, we will reduce the
memory overhead that we currently face by storing these objects for
several thousand (and hopefully, a million in a short while!) objects.

Usually, it is only the bright or interesting objects that users will
want to add links to / store logs about, so it might be a good idea to
dissociate these data from the SkyObject class and store them in a
hash instead.

Besides, it is quite rare that a user will ask for links on an object,
so a hash should be faster.

Regards
Akarsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20080606/37996873/attachment.pgp