| Number of colors of widget appliation [message #17982] |
Tue, 23 November 1999 00:00  |
Carsten Dominik
Messages: 45
Registered: February 1998
|
Member |
|
|
Hi.
I am develloping a widget application with IDL. The widget contains a
couple of draw windows. One displays an image I read from a jpg file,
the other display graphic objectes.
I do not have enough colors in the widget program, and I would like to
use more. Of course I went through Dave Fannings web site and found
the tip how to force IDL to use a certain number of colors.
So I tried to add an COLORS ekyword to the widget_draw commands, but
that does not work. IDL still shares the colors with my desktop and
allocates too few colors.
The I thought: lets try to be clever: I just open a window before I
start my widget application. So I did
IDL> window, colors=200
IDL> launch_my_appl.
What happens is this: The "window" call indeed allocates a large
number of colors. The widget application seems to use many colors as
well, but it dissplays them with the shares color map - totally
wrong. THis is independant of where my cursor is - on the widget or
somewhere else.
Now, when I move the cursor to the window I opened with "window, colors=200",
the draw window in the widget shows the correct colors, but the rest
of the widget is wrong.
So how can I make the main window of a widget allocate its own color
table and share it with all child objects in that widget?
Thanks.
- Carsten, desperate, after a day of fiddling.
--
Carsten Dominik <dominik@astro.uva.nl> \ _ /
Sterrenkundig Instituut "Anton Pannekoek" |X| _
Kruislaan 403; NL-1098 SJ Amsterdam /| |\ _ _ _/ \
phone +31 (20) 525-7477; FAX +31 (20) 525-7484 ___|o|____/ ~~ \___/ ~~~~~
|
|
|
|
| Re: Number of colors of widget appliation [message #18045 is a reply to message #17982] |
Wed, 24 November 1999 00:00  |
Liam Gumley
Messages: 473
Registered: November 1994
|
Senior Member |
|
|
Craig Markwardt wrote:
> davidf@dfanning.com (David Fanning) writes:
>> I guess the thinking now is that this might be a
>> window manager bug, rather than an IDL bug.
>
> This doesn't totally wash with me. After all, the color table *does*
> change for normal draw windows. But I guess this means that (a) it's
> not considered by RSI to be an IDL bug, and thus (b) it won't be
> "fixed."
Since the same behavior has been seen on a Solaris console, a Linux
console, and a Windows NT X-server, I'd say it's an IDL bug.
Cheers,
Liam.
--
Liam E. Gumley
Space Science and Engineering Center, UW-Madison
http://cimss.ssec.wisc.edu/~gumley
|
|
|
|
| Re: Number of colors of widget appliation [message #18046 is a reply to message #17982] |
Wed, 24 November 1999 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
davidf@dfanning.com (David Fanning) writes:
>
> Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
>
>> The point remains: IDL doesn't switch the color tables when entering
>> draw widgets. LOADCT may load a new color table internally into IDL,
>> but it never becomes active on the screen.
>
> I guess the thinking now is that this might be a
> window manager bug, rather than an IDL bug.
This doesn't totally wash with me. After all, the color table *does*
change for normal draw windows. But I guess this means that (a) it's
not considered by RSI to be an IDL bug, and thus (b) it won't be
"fixed."
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Number of colors of widget appliation [message #18051 is a reply to message #17982] |
Wed, 24 November 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
> The point remains: IDL doesn't switch the color tables when entering
> draw widgets. LOADCT may load a new color table internally into IDL,
> but it never becomes active on the screen.
I guess the thinking now is that this might be a
window manager bug, rather than an IDL bug.
Don't you love the problems that get caused by
software having to work together. If only
everybody used JAVA. Whoops! Did I say that!?
Please don't tell the nice folks at Microsoft. :-(
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Number of colors of widget appliation [message #18052 is a reply to message #17982] |
Wed, 24 November 1999 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
davidf@dfanning.com (David Fanning) writes:
> Humm. Yes. Well, I suppose I could believe some funny business
> with private color tables. But I would still make sure
> I tried the expose event idea. If that didn't work,
> something would be *seriously* wrong. :-(
Hmm. Looking back at my notes, I didn't try expose events, but I
*did* try tracking events, which should be the appropriate thing.
Tracking events are generated whenever the mouse enters or leaves the
widget, while expose events only happen when a part of the window is
exposed and needs to be redrawn.
The point remains: IDL doesn't switch the color tables when entering
draw widgets. LOADCT may load a new color table internally into IDL,
but it never becomes active on the screen.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Number of colors of widget appliation [message #18053 is a reply to message #17982] |
Wed, 24 November 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Markus Feldt (mfeldt@mpia-hd.mpg.de) writes:
> I encountered a similar problem a few months ago - it was simply that the
> private colour table which IDL installed when starting with the 'window,
> colors=200' command didn't get used when the mouse pointer was in widget_draw
> window.
>
> I called the tech-support from creaso and they convinced me that it was a
> problem of the OS/WM/IDL combination. They claimed that they didn't support KDE
> on solaris... it works fine though with the generic solaris CDE environment.
That's the word I get, too, from my usually reliable
"well-placed" source. Some window managers just don't
do what they are supposed to do. They remind me of
a couple of children who share this office space with
me. :-(
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Number of colors of widget appliation [message #18055 is a reply to message #17982] |
Wed, 24 November 1999 00:00 |
Markus Feldt
Messages: 6
Registered: November 1999
|
Junior Member |
|
|
Hi Carsten,
I encountered a similar problem a few months ago - it was simply that the
private colour table which IDL installed when starting with the 'window,
colors=200' command didn't get used when the mouse pointer was in widget_draw
window.
I called the tech-support from creaso and they convinced me that it was a
problem of the OS/WM/IDL combination. They claimed that they didn't support KDE
on solaris... it works fine though with the generic solaris CDE environment.
Cheers
Markus
--
/| '` |\ Markus Feldt Voice: +49 6221 528 262
|_| `' |_| Max-Planck-Institut Fax: +49 6221 528 246
-------- fuer Astronomie E-Mail: mfeldt@mpia-hd.mpg.de
| MPIA | Koenigstuhl 17 Web: http://www.astro.uni-jena.de
|________| D-69117 Heidelberg, Germany Si, !asi es la vida!
|
|
|
|
| Re: Number of colors of widget appliation [message #18057 is a reply to message #17982] |
Tue, 23 November 1999 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
davidf@dfanning.com (David Fanning) writes:
>
> Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
>
>> Yes, yes, yes! I described this problem a few weeks ago. My
>> conclusion is that draw widgets do not update their color tables like
>> normal draw windows. This is true for me on Solaris and Linux
>> platforms, IDL 4 through 5.2.1, 8 bit color. While color flashing is
>> annoying, at least it flashes to the *right* colors on a normal draw
>> window. Not so for draw widgets.
>
> I'm not so sure we are talking about the same thing
> here. Are we talking about *direct* graphic draw widgets,
> or *object* graphic draw widgets? A direct graphic draw
> widget should update itself pretty well, although I would
> be prepared to believe you might have to click in it to
> get its attention, maybe.
To be honest, I am not sure what the original post was using.
Personally, I am using:
* 8 bit graphics
* Linux/Solaris X Windows PseudoColor
* direct graphics draw widgets
> In any case, the problem is quite easily solved, I
> think, by physically loading the right color table
> on a draw widget expose event. Hard to see how that
> wouldn't work in direct graphic draw widgets.
Yes I tried this. Not sure if it was tracking events, or expose
events or whatever. I think I got them all :-) The final result was
that loading a color table has *no* effect on direct graphics draw
widgets when the color table is private. Normal direct graphics draw
windows work fine. As the original poster described, when you move
the mouse into the draw window, the color table flashes to the correct
one. The same is not true when you move the mouse pointer into a draw
*widget*.
What can I say, this happens on both Solaris and Linux, so it can't
simply be an X bug...
And to Liam: I totally agree, I don't appreciate color table flashing
at all, and you make some great suggestions to avoid it. However,
there are times where I just can't avoid running two IDL sessions with
different color tables, or have some other annoying program that
slurps up all the colors uncontrollably (PGPLOT anyone?). In that
case, it is preferable to have the color table flash and be correct,
vs. *not* flashing and being incorrect.
Craig
Hopefully RSI doesn't give up on the last .001%.
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Number of colors of widget appliation [message #18059 is a reply to message #17982] |
Tue, 23 November 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
> Yes I tried this. Not sure if it was tracking events, or expose
> events or whatever. I think I got them all :-) The final result was
> that loading a color table has *no* effect on direct graphics draw
> widgets when the color table is private. Normal direct graphics draw
> windows work fine.
Humm. Yes. Well, I suppose I could believe some funny business
with private color tables. But I would still make sure
I tried the expose event idea. If that didn't work,
something would be *seriously* wrong. :-(
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Number of colors of widget appliation [message #18061 is a reply to message #17982] |
Tue, 23 November 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
> Yes, yes, yes! I described this problem a few weeks ago. My
> conclusion is that draw widgets do not update their color tables like
> normal draw windows. This is true for me on Solaris and Linux
> platforms, IDL 4 through 5.2.1, 8 bit color. While color flashing is
> annoying, at least it flashes to the *right* colors on a normal draw
> window. Not so for draw widgets.
I'm not so sure we are talking about the same thing
here. Are we talking about *direct* graphic draw widgets,
or *object* graphic draw widgets? A direct graphic draw
widget should update itself pretty well, although I would
be prepared to believe you might have to click in it to
get its attention, maybe.
In any case, the problem is quite easily solved, I
think, by physically loading the right color table
on a draw widget expose event. Hard to see how that
wouldn't work in direct graphic draw widgets.
> I haven't found a solution to this, but I desperately want one. The
> most tricky thing I've tried is reseting the color table in a
> "tracking" event handler for the draw widget. The handler was
> invoked, but the color tables were not switched.
Huh!? How could this be? I'd have to see this to believe
it, even from such a reliable source as Craig. :-)
> I think that IDL believes that it has the proper color table loaded,
> but forgets to actually load it into the X window manager.
Under *what* color configuration is this? Really hard to
believe.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Number of colors of widget appliation [message #18063 is a reply to message #17982] |
Tue, 23 November 1999 00:00 |
Liam Gumley
Messages: 473
Registered: November 1994
|
Senior Member |
|
|
Craig Markwardt wrote:
> Carsten Dominik <dominik@astro.uva.nl> writes:
>>
>> IDL> window, colors=200
>> IDL> launch_my_appl.
>>
>> What happens is this: The "window" call indeed allocates a large
>> number of colors. The widget application seems to use many colors as
>> well, but it dissplays them with the shares color map - totally
>> wrong. THis is independant of where my cursor is - on the widget or
>> somewhere else.
>>
>> Now, when I move the cursor to the window I opened with "window, colors=200",
>> the draw window in the widget shows the correct colors, but the rest
>> of the widget is wrong.
>
> Yes, yes, yes! I described this problem a few weeks ago. My
> conclusion is that draw widgets do not update their color tables like
> normal draw windows. This is true for me on Solaris and Linux
> platforms, IDL 4 through 5.2.1, 8 bit color. While color flashing is
> annoying, at least it flashes to the *right* colors on a normal draw
> window. Not so for draw widgets.
I see the same behavior when running IDL 5.1 on an SGI, using a Windows
NT PC in 256 color mode with XWin-32 as the display terminal.
Whenever you create windows with a specific number of colors in 8-bit
display mode, you are asking for 'color flashing' to occur. Personally,
I never want to see color flashing when I'm running IDL. Here are some
tips for avoiding color flashing altogether.
(1) Close all existing IDL sessions, and any other applications you have
running on your desktop (especially web browsers).
(2) Start a new IDL session, and type
window, /free, colors=-10 ; (note *minus* 10)
This tells IDL to try and obtain a shared colormap, while reserving 10
colors for use by the desktop. Note that the color table size is
determined when you open the first graphics window in an IDL session,
and it remains fixed for the remainder of the session.
(3) Check the number of colors you have available by typing
print, !d.table_size
(4) Check the display properties by typing
help, /device
Look for the line that says 'Colormap:'
If the number of colors is 100 or higher, and IDL obtained a shared
colormap, then you have an acceptable number of colors available and
color flashing should not occur. The trick is to write your code to use
the system variable !d.table_size to tell you the size of the color
table: don't assume any particular size.
If the number of colors reported is less than 100, or IDL obtained a
private colormap, then your desktop is not allowing IDL to use enough
colors. Solaris boxes running the CDE desktop and Linux boxes running
the GNOME desktop in 8-bit display mode are particularly troublesome in
this respect. Under Solaris, you can modify the CDE color preferences to
tell it to allow 'Most colors for applications', log out, and log back
in. If you are running GNOME on Linux, I have not found a way to make it
use less colors. The only solution I know of is to use a different
window manager, such as fvwm.
Cheers,
Liam.
--
Liam E. Gumley
Space Science and Engineering Center, UW-Madison
http://cimss.ssec.wisc.edu/~gumley
|
|
|
|
| Re: Number of colors of widget appliation [message #18065 is a reply to message #17982] |
Tue, 23 November 1999 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Carsten Dominik <dominik@astro.uva.nl> writes:
>
> IDL> window, colors=200
> IDL> launch_my_appl.
>
> What happens is this: The "window" call indeed allocates a large
> number of colors. The widget application seems to use many colors as
> well, but it dissplays them with the shares color map - totally
> wrong. THis is independant of where my cursor is - on the widget or
> somewhere else.
>
> Now, when I move the cursor to the window I opened with "window, colors=200",
> the draw window in the widget shows the correct colors, but the rest
> of the widget is wrong.
>
Yes, yes, yes! I described this problem a few weeks ago. My
conclusion is that draw widgets do not update their color tables like
normal draw windows. This is true for me on Solaris and Linux
platforms, IDL 4 through 5.2.1, 8 bit color. While color flashing is
annoying, at least it flashes to the *right* colors on a normal draw
window. Not so for draw widgets.
I haven't found a solution to this, but I desperately want one. The
most tricky thing I've tried is reseting the color table in a
"tracking" event handler for the draw widget. The handler was
invoked, but the color tables were not switched.
I think that IDL believes that it has the proper color table loaded,
but forgets to actually load it into the X window manager.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Number of colors of widget appliation [message #18071 is a reply to message #17982] |
Tue, 23 November 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Carsten Dominik (dominik@astro.uva.nl) writes:
>> 1. What version of IDL and on what computer?
>
> IDL Version 5.2 (hp-ux hp_pa). Research Systems, Inc.
>
>> 2. If you start IDL up from scratch and type these commands,
>> how many colors do you have?
>
> Visual Class: PseudoColor (3)
> Bits Per RGB: 8
> Physical Color Map Entries (Used / Total): 256 / 256
Yikes! This shouldn't be happening. Do you have some kind of
start-up file that is setting colors for you? Or, more likely,
did you have Netscape running when you started IDL up? You
will have nothing but trouble (Well, you're in for trouble
anyway. See below.) if you don't get a shared color map. So
this is one strike against you. (Oh, sorry, you probably
don't play baseball in The Netherlands. But this is NOT
good, and if we get to three strikes, you are in BIG trouble!)
>> 3. Are you using direct graphics or object graphics?
>
> Object graphics in general (for the 3 main windows on the
> widget. But I display the little image in a forth window
> (also inside the widget) with a TVSCL command.
>
> That would be called direct graphics, I guess?
Yep. Bad news. I can see the curve ball coming...
S-t-r-i-i-i-k-e Two!
>> 4. How many colors does your display support?
> 8 bit
Ooogh, strike three! I'm afraid that's it. There is nothing
but bad news ahead.
There are several things going on here that are pretty
much conspiring against you in a way that I think will
make it impossible for you to be happy with the way your
colors work.
First of all, getting a private color map on an 8-bit
display pretty much guarantees that your colors will
flash no matter what. The window colors will be in the
shared color map and the IDL graphics colors will be
in a private color map, so every time you move the
cursor from a button in your widget program (the
window colors) to the graphics window (the graphics
colors) you will see a flash. I wouldn't be surprised
if you told me the buttons disappeared. :-(
Second, the object graphics system and the direct
graphics system are two completely different and
separate graphics systems. You can get away with
combining them on a 24-bit display, but you can
almost never get away with it on an 8-bit display.
The reason is, they use colors in a *completely*
different way. So even if you didn't have the
color map problems above, your colors would be
going crazy as you switched focus from an
object graphics window to a direct graphics
window.
In general, I think it is safe to say, you really
shouldn't be using the object graphics system on
an 8-bit display unless you have a VERY good reason
to do so. And then you should make sure that the
entire program is written in the object graphics
system. Don't combine the two graphics systems.
But, first, I would try to sort out why you have
a private color map. You really want to get a
shared color map if at all possible. Without
that you are almost finished before you start. :-(
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
