| RSI / CreaSo survey: Whish list [message #5354] |
Wed, 06 December 1995 00:00  |
hahn
Messages: 108
Registered: November 1993
|
Senior Member |
|
|
As RSI and CreaSo ask the users for future improvements of the product
I started to compile a list of improvements. Here come my thoughts,
unsorted:
Current State: Currently all graphical output is determined solely
by the plot function and parameters passes to it.
Once it is on the screen it is fixed.
Improvement: I would like to use a mouse and click to an axes and
can change the labelling (font, color, ...) and the
region of interest (zoom into my data). Updated viewing
parameters should be reflected on some system variables
(!P.something).
Current State: Labeling of contour plots isn't easy or isn't done as
expected.
Improvement: Better control of the labels.
Improvement: Interactive placement and editing of labels
Current State: 3-D objects are rendered with a primitive light model
only.
Improvement: Better 3-D graphics with more light sources, methods to
place/move the camera etc.
Current State: 3-D objects cannot be exported to other graphical
tools.
Improvement: Output of DXF, Wavefront object files, or STEP is
needed.
Current State: Map projections are sometimes difficult to use when a
strictly given result is required.
Improvement: Better map transform algorithms should be available and
bugs fixed.
Current State: Usage of structures slows down execution time compared
with
using common blocks as structure.
Improvement: More efficient code to handle structures.
Current State: Usage of structures is limited to data.
Improvement: Make IDL more object oriented.
Current State: !P.MULTI is too difficult to use for some layouts. Too
static.
Improvement: More layouts, better handling, interactivity.
Current State: IDL for Windows supports the clipboard only by writing
to it.
OLE is not supported.
Improvement: Make tvrd to read from the clipboard. Support OLE.
More ideas ???
Norbert Hahn
Technische Hochschule Darmstadt
|
|
|
|
| Re: RSI / CreaSo survey: Whish list [message #5468 is a reply to message #5354] |
Tue, 12 December 1995 00:00  |
zawodny
Messages: 121
Registered: August 1992
|
Senior Member |
|
|
In article <4ahq1c$hna@rs18.hrz.th-darmstadt.de> hahn@hrz.th-darmstadt.de (Norbert Hahn) writes:
> kspencer@s.psych.uiuc.edu (Kevin Spencer) wrote:
>
> Well, that depends on how you interpret WYSIWYG:
> I second this idea when the display shows faithfully
> what you get printed. However, the format of the
> display 1024x768 pixels should be read 1024/768 = 4/3
> while the printed paper is 11x8.5 inch ( 11/8.5 = 1.29 ) in the U.S.
If you include a half inch margin on every edge (not unreasonable)
your US paper becomes 10/7.5 which is 4/3!
> a) Setup your plot for the final result (paper) and view
> intermediate results on your screen in the same ratio.
> I would call this WYSIWYG.
>
> b) Setup your plot for the screen and leave some unused
> parts on the paper. WYSIWYG too.
Either of these would be acceptable.
> c) Have intelligent setups for all output devices and IDL
> care for correct results. Difficult to achieve! Although this is
> what IDL currently TRIES (emphasis added) to do.
This is not WYSIWYG, however. Unless you mean that IDL knows the paper
in the printer will be A4 and gives a graphics window with an appropriate
aspect ratio "automatically".
The important thing to note here is that for a WYSIWYG to work IDL must
know something about the printer (I'll argue that it currently knows
nothing about the printer other than emulation) or IDL must impose
standards (like aspect ratio) adhered to by both the Video display and
printer "emulation" software. As is always the case, there are limitations
(particularly in the case of fonts) where some (video/windowing) hard/soft-
ware will not allow for all of the capabilities found in printers (such as
arbitraty rotation of hardware fonts). WYSIWYG works well on Apples/Macs
since THE vendor controlled both the hardware (video and printers) as well
as the software - a definite advantage if not a requirement.
WYSIWYGs are difficult to implement and we are asking for a lot of work
here, but that does not decrease my desire for this "feature" to appear
in a future release.
--
Dr. Joseph M. Zawodny KO4LW NASA Langley Research Center
E-mail: J.M.Zawodny@LaRC.NASA.gov MS-475, Hampton VA, 23681-0001
|
|
|
|
| Re: RSI / CreaSo survey: Whish list [message #5476 is a reply to message #5354] |
Mon, 11 December 1995 00:00 |
hahn
Messages: 108
Registered: November 1993
|
Senior Member |
|
|
kspencer@s.psych.uiuc.edu (Kevin Spencer) wrote:
> In case this hasn't been brought up yet, I would like WYSIWYG graphics.
> It is a pain in the ass to have to format plots differently for output
> to the screen or to a Postscript file.
Well, that depends on how you interpret WYSIWYG:
I second this idea when the display shows faithfully
what you get printed. However, the format of the
display 1024x768 pixels should be read 1024/768 = 4/3
while the printed paper is 11x8.5 inch ( 11/8.5 = 1.29 ) in the
U.S. and all European sizes have a ration of sqrt(2), being
1.41. Actually you have the following choices:
a) Setup your plot for the final result (paper) and view
intermediate results on your screen in the same ratio.
I would call this WYSIWYG.
b) Setup your plot for the screen and leave some unused
parts on the paper. WYSIWYG too.
c) Have intelligent setups for all output devices and IDL
care for correct results. Difficult to achieve! Although this is
what IDL currently tries to do. I modified phaser.pro (which
was supplied in the old userlib) to correctly setup the
PostScript driver for our various PS printers. This is friendly
to our end-users but requires some labour when a new version
of IDL arrrives.
And what should a new version of IDL do ?
It should support all versions discussed above but in a more
general manner: IDL should keep track of how a plot was generated
on the last active output device and should automatically repeat this
sequence when the output device is changed. Of course IDL has to
adapt to the new output device.
This can be done: Before we migrated to IDL we had some 2-D-
visualization program which had two selectable output devices
called primary device and secondary device. The standard setup
was the display for the primary device and i.e. a PostScript driver
for the secondary device. All commands send to the primary device
were stored in a temporary memory and re-interpreted for the
secondary device when the command "send" was entered.
> -----------------------------------------------------------
> Kevin Spencer
> Cognitive Psychophysiology Laboratory and Beckman Institute
> University of Illinois at Urbana-Champaign
> kspencer@p300.cpl.uiuc.edu / kspencer@psych.uiuc.edu
> -----------------------------------------------------------
Add your comments here....
Norbert Hahn
|
|
|
|
| Re: RSI / CreaSo survey: Whish list [message #5479 is a reply to message #5354] |
Fri, 08 December 1995 00:00 |
zawodny
Messages: 121
Registered: August 1992
|
Senior Member |
|
|
Well since a few other folks are airing their wishes, here are mine.
- IDL Compiler for development of standalone applications. Yes I would
like to distribute or even sell some programs without requiring the end
user to shuck out $1500 for IDL first. Now if IDL was only a couple
of hundred bucks well... maybe we would not need this capability. I would
not mind buying this compiler as a separate option.
- Multi threading for asynchronous widget event processing (eg. this could
get you your desired command prompt while running a widget).
- WYSIWYG for printing (sorely needed and a very high priority on my list)
- Lower cost for IDL for Linux for current licensed users (like $250)
- The Hypertext help needs a lot of work (too slow and search engine lousy)
- Standardized parameter order for similar functions (like INTERPOLATE
and ITNERPOL, SPLINE, ...)
- Special widgets for low res (ie notebook computer) displays. These should
be "micro sized" and expand to usable/readable size when the cursor passes
over them.
- Dual color tables. One for "standard items" such as foreground/ background
axis lines and labels (this might be only 2-5 colors in length). The
second for color images and contour plots. This way there would be no need
for twiddling either fore/back-ground keywords or scaling images to fit
above, below, or between the "standard colors" in a single color table.
If you have run into the problem, then you know what I mean. Maybe this
could be implemented by adding a few system variables.
--
Dr. Joseph M. Zawodny KO4LW NASA Langley Research Center
E-mail: J.M.Zawodny@LaRC.NASA.gov MS-475, Hampton VA, 23681-0001
|
|
|
|
|
|
| Re: RSI / CreaSo survey: Whish list [message #5488 is a reply to message #5354] |
Fri, 08 December 1995 00:00 |
peter
Messages: 80
Registered: February 1994
|
Member |
|
|
Joseph M Zawodny (zawodny@arbd0.larc.nasa.gov) wrote:
: Well since a few other folks are airing their wishes, here are mine.
: - IDL Compiler for development of standalone applications. Yes I would
: like to distribute or even sell some programs without requiring the end
: user to shuck out $1500 for IDL first. Now if IDL was only a couple
: of hundred bucks well... maybe we would not need this capability. I would
: not mind buying this compiler as a separate option.
Yes.
: - Multi threading for asynchronous widget event processing (eg. this could
: get you your desired command prompt while running a widget).
Yes.
: - WYSIWYG for printing (sorely needed and a very high priority on my list)
Absolutely. Since this implies keeping some internal series of commands
to be repeated when the user asks for printing, extend this to automatic
replot when windows are resized.
: - Dual color tables. One for "standard items" such as foreground/ background
: axis lines and labels (this might be only 2-5 colors in length). The
: second for color images and contour plots. This way there would be no need
: for twiddling either fore/back-ground keywords or scaling images to fit
: above, below, or between the "standard colors" in a single color table.
: If you have run into the problem, then you know what I mean. Maybe this
: could be implemented by adding a few system variables.
This interacts with the above, since it is images in particular that
don't WYSIWYG very easily.
I'd ask for some work on the programming environment for those of us who
write large applications. Breakpoint should be able to find the source
code for any routine that lies along the path, without needing explicit
pathnames (the interpreter can find them, why can't breakpoint?). This
becomes incredibly exasperating if your source code is split over more
than one directory. If I set a breakpoint on a line, execution should
stop BEFORE that line, not after. This might seem trivial, but try
setting a breakpoint in a routine which has a for loop followed
immediately by a return. You can't set the breakpoint anywhere useful.
When I'm stopped at a breakpoint, I should be able to look at the
context of any routine on the call stack, so that I can, for example,
find out what values the stopped-in routine was called with.
Apart from that, great product!
Peter
--------------------------------
Peter Webb, HP Labs Medical Dept
E-Mail: peter_webb@hpl.hp.com
Phone: (415) 813-3756
|
|
|
|
| Re: RSI / CreaSo survey: Whish list [message #5489 is a reply to message #5354] |
Fri, 08 December 1995 00:00 |
wmc
Messages: 117
Registered: February 1995
|
Senior Member |
|
|
In article kme@vixen.cso.uiuc.edu, kspencer@s.psych.uiuc.edu (Kevin Spencer) writes:
> In case this hasn't been brought up yet, I would like WYSIWYG graphics.
> It is a pain in the ass to have to format plots differently for output
> to the screen or to a Postscript file.
Seconded!
An while I'm here, I'd also like a /over keyword to plot, which would then act
exactly like oplot (allowing for i=0,3 do plot,x(i,*),ov=(i ne 1))
and would also accept (and ignore) keywords such as /xstyle that are irrelevant for
overplotting.
---
William M Connolley/wmc@bas.ac.uk/(01223)251479
http://www.nerc-bas.ac.uk/public/icd/wmc/
Climate Modeller, British Antarctic Survey
|
|
|
|
| Re: RSI / CreaSo survey: Whish list [message #5492 is a reply to message #5354] |
Thu, 07 December 1995 00:00 |
kspencer
Messages: 21
Registered: December 1993
|
Junior Member |
|
|
In case this hasn't been brought up yet, I would like WYSIWYG graphics.
It is a pain in the ass to have to format plots differently for output
to the screen or to a Postscript file.
-----------------------------------------------------------
Kevin Spencer
Cognitive Psychophysiology Laboratory and Beckman Institute
University of Illinois at Urbana-Champaign
kspencer@p300.cpl.uiuc.edu / kspencer@psych.uiuc.edu
-----------------------------------------------------------
|
|
|
|
| Re: RSI / CreaSo survey: Whish list [message #5495 is a reply to message #5354] |
Thu, 07 December 1995 00:00 |
llobet
Messages: 10
Registered: May 1993
|
Junior Member |
|
|
May I add a couple of suggestions?
To be able to print or to create a print file out of a window created
interactively, without having to repeat all the commands used to create
that window.
Using cut and paste to repeat a whole set of statements, it would be
very helpful to have IDL to ignore the prompt at the beginning of the lines.
-xavier
|
|
|
|
| Re: RSI / CreaSo survey: Whish list [message #5496 is a reply to message #5354] |
Thu, 07 December 1995 00:00 |
Jackel
Messages: 30
Registered: April 1993
|
Member |
|
|
In article <4a6ak3$k0v@ratatosk.uio.no> steinhh@amon.uio.no (Stein Vidar Hagfors Haugan) writes:
[Some good ideas deleted]
I just wanted to add my vote for the following features:
> 3. Possibility of Macros, e.g.:
> #define ABORT(text) BEGIN & MESSAGE,TEXT,/CONTINUE & RETURN,-1 & END
Definitely. I find myself _not_ using lots of small functions, because
otherwise the results from HELP,/ROUTINES becomes useless.
> 5. Different brackets for array subscripts and function calls.
Or just some way of distinguishing between arrays and functions. A
programmer shouldn't have to wonder whether a variable name will conflict with
some other previously defined function.
> Stein Vidar
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
