Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
I tend to loose The colors I choose I got the IDL blues The colors are flashing The session is crashing Labels have strange sizing rules The online help won't work: The display becomes weird And the scrollbars are of no use [guitar solo] IDL 5 behaves bad My widgets go mad Yeah, I tell ya, I got the ol' IDL blues Yes, I'm okay, just too many IDL problems today, maybe I also drank too much tea. But why does the IDL online help scroll nearly two pages down if I press the arrows, and not even one when I click between scrollbar and arrow? Why do I sometimes have to mark the text to make it visible? Why do my widgets size themselves wrong in IDL5? Problem of the day: When there are too few free color cells for my IDL application, I use the COLORS keyword in the first WINDOW command to create my own color table with as many colors I want. Now, is there a way to tell IDL which colors to take, and to keep some of the lower color cells intact? That's where the system colors are, and the colors of IDL's widgets. It is very annoying when the display flashes when I enter and leave windows. And the other application that has all the colors (it's another IDL session, BTW) doesn't even have open windows at the time, so I would not notice any flashing. Sun UltraSparc, Solaris 2.5. Alex, waiting for IDL 5.0.2 -- Alex Schuster Wonko@weird.cologne.de PGP Key available alex@pet.mpin-koeln.mpg.de
Alex Schuster wrote: > > Aviv Gladman wrote: > >> We used to have the colourmap swapping problem on our 24-bit Ultras, which >> kind of surprised me as there is really no concept of colourmaps for a >> 24-bit display. In DirectColor mode, IDL tries to grab all 16 million odd >> colours into a private colourmap, resulting in the flashing. You can >> probably solve you problem using the DEVICE, TRUECOLOR=24 . the DEVICE, >> DECOMPOSED=0 or DEVICE, DECOMPOSED=1 commands can then be used to turn >> on/off 8-bit colour mapping (in one mode, 24-bit colours are mapped to the >> loaded 8-bit colour palette so TV and PLOTS use a 256 colour palette that >> can be loaded via XLOADCT, in the other mode, 24-bit colours are as >> expected, RGB settings, and images always seem to use an greyscale >> palette in this mode). When swapping colourmaps in 8-bit emulation, you >> have to redraw the window to get the colour change to have an effect >> (since you aren't actually changing the colour palette, you're just >> changing the RGB colour mappings). > You might try putting the following in your /usr/openwin/lib/Xdefaults (or .Xdefaults) file: Idl*colors: -10 This tells IDL to reserve 10 colors before grabbing color indices, thereby sparing colors used by the system. Dave -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ David S. Foster Univ. of California, San Diego Programmer/Analyst Brain Image Analysis Laboratory foster@bial1.ucsd.edu Department of Psychiatry (619) 622-5892 8950 Via La Jolla Drive, Suite 2200 La Jolla, CA 92037 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
Aviv Gladman wrote: > We used to have the colourmap swapping problem on our 24-bit Ultras, which > kind of surprised me as there is really no concept of colourmaps for a > 24-bit display. In DirectColor mode, IDL tries to grab all 16 million odd > colours into a private colourmap, resulting in the flashing. You can > probably solve you problem using the DEVICE, TRUECOLOR=24 . the DEVICE, > DECOMPOSED=0 or DEVICE, DECOMPOSED=1 commands can then be used to turn > on/off 8-bit colour mapping (in one mode, 24-bit colours are mapped to the > loaded 8-bit colour palette so TV and PLOTS use a 256 colour palette that > can be loaded via XLOADCT, in the other mode, 24-bit colours are as > expected, RGB settings, and images always seem to use an greyscale > palette in this mode). When swapping colourmaps in 8-bit emulation, you > have to redraw the window to get the colour change to have an effect > (since you aren't actually changing the colour palette, you're just > changing the RGB colour mappings). Aviv, thanks for your answer. But the problem is not so much the swapping of the colormaps. It's that when I tell IDL to take 32 colors, it takes the absolute color cells 0-31. This is where some system colors are, eg. colors for the window manager, and the color of IDL's widgets. If I could tell IDL to take, say, the color cells 224-255, the swapping would affect only the application that uses those colr cells. Sorry, I wasn't very clear there. At the UltraSparc with 24-bit display the problem can be solved by DEVICE, PSEUDO=8. The results are similar as with DEVICE, TRUE_COLOR=24 and DEVICE, DECOMPOSED=0, but the display deems to be faster. However, we also have 8-bit SUNs, and there it no way to prevent the swapping. Alex
We used to have the colourmap swapping problem on our 24-bit Ultras, which kind of surprised me as there is really no concept of colourmaps for a 24-bit display. In DirectColor mode, IDL tries to grab all 16 million odd colours into a private colourmap, resulting in the flashing. You can probably solve you problem using the DEVICE, TRUECOLOR=24 . the DEVICE, DECOMPOSED=0 or DEVICE, DECOMPOSED=1 commands can then be used to turn on/off 8-bit colour mapping (in one mode, 24-bit colours are mapped to the loaded 8-bit colour palette so TV and PLOTS use a 256 colour palette that can be loaded via XLOADCT, in the other mode, 24-bit colours are as expected, RGB settings, and images always seem to use an greyscale palette in this mode). When swapping colourmaps in 8-bit emulation, you have to redraw the window to get the colour change to have an effect (since you aren't actually changing the colour palette, you're just changing the RGB colour mappings). Aviv S. Gladman On 11 Aug 1997, Alex Schuster wrote: > [poem snipped, hey, we have to save bandwith, right?] > > Problem of the day: When there are too few free color cells for my IDL > application, I use the COLORS keyword in the first WINDOW command to > create my own color table with as many colors I want. > Now, is there a way to tell IDL which colors to take, and to keep some > of the lower color cells intact? That's where the system colors are, and > the colors of IDL's widgets. > It is very annoying when the display flashes when I enter and leave > windows. And the other application that has all the colors (it's another > IDL session, BTW) doesn't even have open windows at the time, so I would > not notice any flashing. > > Sun UltraSparc, Solaris 2.5. > > Alex, waiting for IDL 5.0.2 > -- > Alex Schuster Wonko@weird.cologne.de PGP Key available > alex@pet.mpin-koeln.mpg.de > >
David Foster wrote: > You might try putting the following in your > /usr/openwin/lib/Xdefaults (or .Xdefaults) file: > > Idl*colors: -10 > > This tells IDL to reserve 10 colors before grabbing color indices, > thereby sparing colors used by the system. I tried this on some of our 8-bit Suns, but didn't notice any change. I started an IDL session, opened a window, and IDL grabbed all available colors. Okay so far. Then I starten another session, and opened a window with COLORS=50. When I moved the mouse into the window, the color table was changed, and the 50 colors allocated the first 50 cells. Maybe this problem related to OpenWindows 3.4? (No, I did not forget to xrdb the .Xdefaults file.) BTW, where does one find information about the entries in the .Xdefaults file? The only iformation I found was in $IDL_DIR/resource/X11/lib/X11/app-defaults/Idl, it wasn't of much help. Lines like ! Size, resize behavior of the File Selection box, dialog_pickfile() Idl*XmFileSelectionBox.resizePolicy: XmRESIZE_GROW Idl*XmFileSelectionBox.width: 400 look promising. Alex -- Alex Schuster Wonko@weird.cologne.de PGP Key available alex@pet.mpin-koeln.mpg.de
Alex, Since you are using a Sun UltraSparc, your problem with the colors may primarily be that the window manager is still using pseudoColor even though your system supports trueColor. If you copy the file /usr/dt/config/Xservers to /etc/dt/config (you may have to create a config directory) and edit the last line to read :0 Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -dev /dev/ffb0 defdepth 24 your desktop colors should become trueColor colors. This will work even if you are still using openwindows. You may have to reboot for the change to take place. Paul Paul Crain p.d.crain@larc.nasa.gov