Hi Jari,

> Speaking as someone having used Guide since version 1 and never really
> tried anything else beyond a quick glance: A more modern user interface
> starting with new menu organisation, dialogs and look-and-feel. Too much
> VGA and DOS legacy stuff here, methinks. (You didn't say the suggestion
> should be easy to implement :D )

True, a lot of the layout results from things having "just grown".
For example: most of the more recent things displayed in Guide have a
common control system, with a dialog wherein one can select color,
display levels, limiting magnitude, and so on. But some are accessed
as user-added datasets; some are accessed elsewhere. And some things
(such as the datasets controlled in Data Shown) have a totally different
interface. I really like the current Display dialog, but there are
a lot of things that need to be revised to use it as well.

> One other thing I sometimes think about is a click-and-point tool to
> make TDFs. It could well be a stand-alone program allowing one to load a
> data file into the 'TDF-editor' and defining what each column of data is.

I _did_ write (for my own use, thus far) a tool that reads in a FITS
file produced by VizieR and generates a passable .TDF. The benefit of
this is that a FITS file contains complete column specifications in a
somewhat standard form. Some human interaction is still required, but
if I can make it a tool for wider distribution, it should help a lot.
For an example, take a look in 'vizier.tdf', at the description for
SDSS-7. That dataset had dozens of columns; due to the wonders of FITS,
I was able to get most of them described in the .TDF without much work.

> One smaller suggestion: A better Goto RA & decl. with the same kind of
> intelligence as the general time setting function. I'd like to
> copy/paste a combination of RA & delc into an edit box it and it figures
> it out. (The current one is very picky about the format and you have two
> separete edit boxes.)

Um. That's a really good point...

I made the general time setting function extremely un-picky, because
I was tired of having to remember how it ought to work. I wanted it to
recognize anything a human would. Which includes things such as
"31o99". If a human had to guess, she would assume that meant 31 October
1999. And Guide will now guess that, too... or that "f 3:14:16" means the
nearest Friday at 3:14:16.

Similar logic for the RA/dec dialog wouldn't be quite so easy. I do
have some of this already in there; for example, six digits (possibly
followed by .nnnnn) is assumed to be hhmmss.sss or dd''""."""". It can
also recognize RAs of "3 14.15" as 3h 14.15m, "314.159d" as 314.159
degrees, and so on. But you're right, it could stand to be smarter
about this... in particular, if the RA and dec are both in the RA box,
the program ought to be able to figure out what the user meant. It'd be
particularly useful when one cuts-and-pastes an RA/dec from another source.

-- Bill