[Kstars-devel] possible features

[Dirk Huenniger]

Thanks for your comments Jasem,

>Hello Dirk,
>
>Can you provide a link for your GTK app?
>
>  
>
Yes, the following log explains how to download, compile, execute and 
test the programm

download http://www.astro.uni-bonn.de/~dhun/gb.tar
tar -xvzf gb.tar
cd gb/lib/iniparser/
make
cd ../cfitsio/
./configure
make
cd ../..
./configure
make
cd src
./gboccia
Start Exposure
Lastname
Play with birghness contrast gamma
Tools -> CCU Control  (The terminal!)
wait until exposure is finished
press saods9 button (only if shell command"saod9" starts external viewer)
look at picture
exit saods9
multiple Exposure and Queue don't work because there is no hardware
play play play
File-> Quit

>>Preview:
>>
>>    
>>
>
>Brightness, contrast, gamma can be represented as INumbers. The preview can be 
>represented as an 8-bit FITS BLOB sent to KStars whenever you desire. 
>  
>
Yes in principle that would be a good idea.  But note that you will have 
to send the whole preview image whenever the user changes the display 
options. Our Telesope will have a 8 Kbyte/s connection (256x256Pixel 
preview) => 8s per image , undisirable. Futhermore Kstars pops up a 
window whenever a fitsblob is received, so you could in princible adjust 
the parameters, press transmit, look at the fitsfile. Adjust parameters 
and so  on. But it's fancyer if you grab the brighness slider with the 
left mousebutton and drag it around while your preview changes 
accordingly.  As for the bandwidth issue,  it would be usefull to 
transfer blocks of lets say 1024 bytes of 16 Bit data to client using 
blobs, as soon a the neccessary portion of the CCD has been read out. 
And downconvert to 8 bit on the client side.
CCD readout takes a minute, so needs 1KB/s. And the user can play with 
brightness contrast as much as s/he likes.

>>Popups:
>>Some important messages are displayed in a Popup window that closes on
>>OK button.
>>    
>>
>
>Not possible in current GUI. Furthermore, messages are not classified in INDI, 
>and thus you cannot distinguish "important" messages from others.
>
>  
>
For example the could be an
static IText aText[] = {{"IMPORTANTMSG", "this is important"}};
static ITextVectorProperty vText = {mydev, "IMPORTANT", "very 
important", main_group , IP_RO, 0, IPS_OK, aText, NARRAY(aText)};

And whenever a vector with name= "IMPORTANT" is received, the important 
message is displayed in a popup.

>>Terminal:
>>There is a Terminal window that displays the commands send to the CCD
>>Controller on the left side and the messages received from it on the
>>right side of a scrollable columned list. Furthermore it provides a
>>command line in which the user can send commands directly to the
>>Controller.
>>    
>>
>
>To send a pure command, just define IP_RW IText property that should carry the 
>command to the driver. 
>
>  
>
Yes I did so. And it works of course. The problem is to display what has 
been sent and what has been received such that you can quickly figure 
out communication problems.

>>Hotkeys:
>>An exposure is stated by pressing F2 ENTER. An a flushing of the CCD is
>>initiated by F7 ENTER.
>>    
>>
>
>Not possible now. 
>  
>
Not really Important

>The general philosophy behind INDI is that devices should be able to describe 
>themselves, and clients should not know anything about devices. Therefore, 
>KStars doesn't know "capturing" or "flushing" per se. KStars is only aware of 
>INDI Standard Properties which represent the most important properties found 
>in astronomical devices (refer to the INDI developers manual for more 
>details).
>
>KStars is completely ignorant of all other device properties and makes no 
>arrangements to treat them specially. This is why a dynamical GUI is built to 
>allow the operator to control the device. Afterall, KStars doesn't really 
>know much about devices. One can write an INDI driver for a toaster and 
>KStars will run it.
>  
>
Cool I will try to do it if I find the time :-).

>I will add new INDI GUI features to KStars if I see them _important_ and 
>_general_ enough. If you feel that KStars lacks some features you absolutely 
>require for your specific project, feel free to add whatever features to 
>KStars, it's open source and free after all!
>  
>
If my professor agrees I will do.

Cheers Dirk