[Kstars-devel] GSoC 2012: Project Introduction: Logs and Data

[Rishab Arora]

Apologies for the late reply.
Very short version: http://blog.rishab.in/the-log-viewer/

Yes, I plan to separate the storage of observation logs from SkyObject.
>From my current understanding, KStars currently writes the user log to a
file as well as stores it in "userlog.dat" when it needs to save data.
During initialization, the log is read from the text files and stored with
the SkyObject.

In my proposal, I plan to make a separate database in which I will (along
with all required information like seeing, equipment etc) store an
identifier for the star. This identifier could be the 'name' as is being
used currently, but I plan to use the HD index instead so that the logs
aren't limited to a set number of stars. Similarly, a unique identifier
(which will be assigned when I port the DSO catalog to SQLite) will be
used.

Using the name will make it work for all the objects it currently supports
at least.

When the detail dialog will display the log tab, I plan to query the
database and populate a list of logs in a UI similar to this.
http://blog.rishab.in/wp-content/uploads/2012/04/mockup.png


"""
>From UI point. it's very bad to force user to fill in _all_ fields.
Users are lazy and always have strange ideas. It's better to avoid
annoying constraints like: «you'll have to explicitly state all
information».
"""

I agree, but what I was pointing out was that in the current log
implementation, one needs to write these fields if he/she needs them.
In the new implementation, all this will already be filled.

There's a very rough diagram for the user database at
http://blog.rishab.in/wp-content/uploads/2012/04/user.jpeg . Though not all
fields are represented here, it should show how I plan to store the logs,
and how I plan to retrieve redundant information from KStars instead of
needing the user to type.

I would appreciate any advice/suggestions you have. It's better to get
things reviewed before I implement something that is wrong.

Thanks for taking the time to read through this. :)

Rishab Arora
(spacetime)
@spacetime29 <https://twitter.com/#%21/spacetime29>
Find me on Google+ <https://plus.google.com/118197889888669218025/posts>




On Sun, Apr 29, 2012 at 11:00 PM, Aleksey Khudyakov <
alexey.skladnoy at gmail.com> wrote:

> On 26.04.2012 20:44, Rishab Arora wrote:
>
>> Hey Aleksey!
>>
>>
>> Regarding the observation logs, currently we have a feature which lets
>> us save a plain text entry for named objects (accessed by right clicking
>> -> logs). So if you wish to store what you saw while observing, say
>> Saturn, you'll have to explicitly state all information like the
>> equipment you've used, date, time etc which is already available to
>> KStars.
>> I plan to replace this view with a new interface linked with a database.
>> Hence, when you right click and select Logs in the proposed
>> implementation, you'll get a list of all previous entries. And the
>> option to add new entries. And to export these entries (as OAL files,
>> hopefully)
>>
>>  There is a problem. Current implementation stores logs and some other
> info in the SkyObject. This approach is problematic for following reasons:
> is object is destroyed all data is lost. At the moment only faint star are
> loaded and unloaded to/from memory on demand.
> Galaxies are very numerous too so at some point we may want to unload them
> too. Also there is no easy way to get all observation logs etc.
>
> It sounds like you want to store observation log separately from
> sky object. So how do you plan link them?
>
>
> From UI point. it's very bad to force user to fill in _all_ fields.
> Users are lazy and always have strange ideas. It's better to avoid
> annoying constraints like: «you'll have to explicitly state all
> information».
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20120501/3cef9838/attachment.html>