Apologies for the late reply. <br>Very short version: <a href="http://blog.rishab.in/the-log-viewer/">http://blog.rishab.in/the-log-viewer/</a><br><br>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. <br>

During initialization, the log is read from the text files and stored with the SkyObject.<br><br>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. <br>

<br>Using the name will make it work for all the objects it currently supports at least.<br><br>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.<br clear="all">

<a href="http://blog.rishab.in/wp-content/uploads/2012/04/mockup.png">http://blog.rishab.in/wp-content/uploads/2012/04/mockup.png</a><br><br><br>"""<br>
>From UI point. it's very bad to force user to fill in _all_ fields.<br>
Users are lazy and always have strange ideas. It's better to avoid<br>
annoying constraints like: «you'll have to explicitly state all information».<br>"""<br><br>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.<br>

In the new implementation, all this will already be filled. <br><br>There's a very rough diagram for the user database at <a href="http://blog.rishab.in/wp-content/uploads/2012/04/user.jpeg">http://blog.rishab.in/wp-content/uploads/2012/04/user.jpeg</a> . 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.<br>

<br>I would appreciate any advice/suggestions you have. It's better to get things reviewed before I implement something that is wrong. <br><br>Thanks for taking the time to read through this. :)<br><br><span style="color:rgb(0,0,0)">Rishab Arora <br>

(spacetime)<br><a href="https://twitter.com/#%21/spacetime29" target="_blank">@spacetime29</a><br>
Find me on <a href="https://plus.google.com/118197889888669218025/posts" target="_blank">Google+</a></span><br><br><br>
<br><br><div class="gmail_quote">On Sun, Apr 29, 2012 at 11:00 PM, Aleksey Khudyakov <span dir="ltr"><<a href="mailto:alexey.skladnoy@gmail.com" target="_blank">alexey.skladnoy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On 26.04.2012 20:44, Rishab Arora wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey Aleksey!<div class="im"><br>
<br>
Regarding the observation logs, currently we have a feature which lets<br>
us save a plain text entry for named objects (accessed by right clicking<br>
-> logs). So if you wish to store what you saw while observing, say<br>
Saturn, you'll have to explicitly state all information like the<br>
equipment you've used, date, time etc which is already available to KStars.<br>
I plan to replace this view with a new interface linked with a database.<br>
Hence, when you right click and select Logs in the proposed<br>
implementation, you'll get a list of all previous entries. And the<br>
option to add new entries. And to export these entries (as OAL files,<br>
hopefully)<br>
<br>
</div></blockquote>
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.<br>


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.<br>
<br>
It sounds like you want to store observation log separately from<br>
sky object. So how do you plan link them?<br>
<br>
<br>
>From UI point. it's very bad to force user to fill in _all_ fields.<br>
Users are lazy and always have strange ideas. It's better to avoid<br>
annoying constraints like: «you'll have to explicitly state all information».<br>
</blockquote></div><br>