| Re: Top 10 IDL Requests [message #20652 is a reply to message #20651] |
Mon, 17 July 2000 00:00   |
Patrick Broos
Messages: 27
Registered: December 1996
|
Junior Member |
|
|
> So, here is the deal. If you feel inclined to
> submit a couple of ideas to this newsgroup, I
> will collect them and submit them personally
> to the VP. I'll even follow up and make sure
> he has, uh, read them. :-)
David,
Thanks for working to improve IDL on behalf of the user community. I
don't have
any humorous thoughts this morning, but here are some ideas that you
might consider.
* Like you, I have spent a lot of effort working around IDL's very
primitive handling
of color. I eventually developed an environment for my own applications
(as you have)
that allows 8 & 24 bit color, X and PostScript devices, user-defined
color tables, and
named colors (e.g. "red"). For the beginning user however there is a
tremendous
learning curve to do something like, say, tvscl an image user a
specified color table,
draw a "blue" box on it (where blue is not in the given color table),
and print it out
in color PostScript. Surely more of this could be available "out of the
box".
* Similarly, it takes a great deal of reading and effort to mix images
and plot axes.
Yes, you've done it, I've done it, and many folks have done it, but it
remains a
significant obstacle for new users.
* It would be nice if RSI better supported the administration of IDL at
a user site
(as opposed to single-user installations). For example, it would be
convenient if
the IDL administrator had a convenient way to supply IDL_PATH and
IDL_STARTUP
values to all users, while retaining the user's ability to supply
additional path and
startup information. I wrote a script to do this
(http://www.astro.psu.edu/users/patb/psu_idl)
but RSI could support this problem more directly.
* As I've ranted and raved before, I still think RANDOMN() and RANDOMU()
have
such a checkered history of bugs and very poor semantics that they
should be
retired and replaced with a new routine of better design.
* A lot of code could be streamlined if IDL widely supported the concept
of a zero-length
array (distinguished from an undefined variable). Think how useful the
concept of
the null string is in string processing.
Thanks,
Pat
============================================================ ========
Patrick S. Broos, Systems Analyst/Programmer patb@astro.psu.edu
Department of Astronomy and Astrophysics My office 814-863-7947
Penn State University
525 Davey Lab FAX 814-863-8686
University Park, PA 16802-6305
http://www.astro.psu.edu Group office 863-9550
============================================================ ========
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
