[Kstars-devel] A short mockup of my GSoC ideas.

[Akarsh Simha]

Hi Prakash

> Some Changes I've planned :
> 
> Observing list :
> Add Rise and Set times. -> Should not be any trouble.

Fine.

> Add a filter by type. -> Similar implementation like FindDialog.

I don't see why this is required, if you provide 'sort by type'
feature. If you have a filter by type, the user is seeing a part of
his observing list, whereas 'sort by type' shows him the entire list
without any loss of ease, IMO.

> Observing logs :
> Create a QGroupBox kinda thingi to make it user friendly. -> It'll look
> something like http://doc.trolltech.com/4.4/images/parent-child-widgets.png
> Store the logs in a meaningful format.

In the backends, this would probably be a good XML format, with
structures for Describing equipment (telescopes, eyepieces...),
observing sites and observing "sessions".

> Widgets of :
> AltVsTime -> Need to investigate further on the crash. Seems like its
> a widget already!
> A click on this should take to the man AVT window.

You probably meant "main AVT window" ;-). It's good news that AVT is a
widget.

> IMO :  I'll have to create a new AVT widget which just plots the graph
> and provide a wrapper window for using the existant tool/call it for
> inclusion in Obslist.

Right. I suggest you separate the plotter bit of AVT and make a widget
out of it. You could then embed this into the avtUI widget.

> SkyCalendar
> I'm thinking of making this tool functional to all objects, so I need
> to see if this  :
> 1. Feasible
> 2. Generalize if it can be done
> 3. Add filters, etc.
> -- Basically a lot of work to be done, which is not exactly related to the GSoC
> but needs to be done to make the SkyCalendar a non-redundant and useful tool.
> What should I do about this ?

Hmm... This sounds like a good idea. Although rise and set times are
relatively straightforward for deep-sky objects in comparison to
planets, it will be a useful tool to have. I don't know how one would
go about doing this, though. ISTM that it almost amounts to having to
re-write SkyCalendar - if this is the case, you might want to keep
this for later. I'll take a look at the code and see if I'm talking
sense.

(It would also be a nice idea to display conjunctions in the sky
calendar.)

> DSS Image
> - Research not done yet.

This one should be simple, but rather useful. Ideally, we should have
a facility to cache the images of all objects in the observing list on
the harddisk, so that when I take my laptop to the field for instance,
I can always see if I've found a supernova in a galaxy, or it's just
some old Milky Way star.

> FOV tool
> - Research not done yet.

What exactly do you want to do with the FOV tool?

> Changes to Existing tools,
> 
> "Add to Observing list" button in :
> 1. WUT
> 2. Conjunctions tool
Good idea. 

> 3. FindDialog -> To make things easier for me | Increase Usability.

I still think it should be the other way round - I must be able to add
object to observing list from the Observing List dialog. Having an add
object to observing list in the find dialog feels out-of-place for me,
but that's okay.



> Is it necessary to add it in all these places ?
> 
> Buttons to be added within the list
> 1. Conjunctions
> 2. FindDialog
> 3. WutDialog

This sounds okay. IIUC, you suggest that we add the facility to invoke
these dialogs from the Observing List dialog. Fine.

> INDI

What exactly do you want to do with INDI?

> Storage format for logs

I'll do some homework here and find out how feasible the COMAST XML
schema is.

Regards
Akarsh