| Re: Strange Linux colors [message #19238] |
Thu, 02 March 2000 00:00 |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
... I have had no trouble with kde (but running in 32 bpp mode). So far
I discovered
no other application that would choke in this mode - but I've been told
there is these
really old custom made tool from xyz which only runs in 8 bpp mode ...
Cheers,
Martin
PS: isn't it one of the virtues of a typical linux box (intel based PC)
that you can finally use more than 256 colors with standard hardware?
Udo Grabowski wrote:
>
> Hello !
>
> We have the same trouble with Idl, and (for direct graphics) it's
> a flaw of the fvwm window manager which does not handle private
> colormaps in widgets correctly. Get the newest fvwm2 release from
> www.fvwm.org, which has a patch for that problem. For object graphics,
> there currently is no way to get the correct colors on fvwm when a
> private colormap is needed, I currently try to get some ideas from
> a former developer of RSI for a patch. As a workaround, close all
> color sucking applications such as netscape, java applications etc.
> until enough colors are available (do a 'print,!d.n_colors' after
> launching an idl window do see how many are allocated). This will
> help in most cases. But you will have no chance if the application
> itself allocates a colormap with 256 entries, which always results
> in a private colormap. The only way to get out of that is to start
> the Xserver with 24 bit RGB color (modify /etc/XF86Config), which provides
> always enough colors to avoid a private colormap, but some other
> applications cannot handle that mode correctly, so expect to have to
> switch back from 24 to 8 bit sometimes. I don't know if the KDE manager
> does a better job on the colormaps.
> --
> Dr. Udo Grabowski email: udo.grabowski@imk.fzk.de
> Institut f. Meteorologie und Klimaforschung II, Forschungszentrum Karslruhe
> Postfach 3640, D-76021 Karlsruhe, Germany Tel: (+49) 7247 82-6026
> http://www.fzk.de/imk/imk2/ame/grabowski/ Fax: " -6141
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 41173-298 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
| Re: Strange Linux colors [message #19247 is a reply to message #19238] |
Wed, 01 March 2000 00:00  |
Udo Grabowski
Messages: 17
Registered: February 2000
|
Junior Member |
|
|
Hello !
We have the same trouble with Idl, and (for direct graphics) it's
a flaw of the fvwm window manager which does not handle private
colormaps in widgets correctly. Get the newest fvwm2 release from
www.fvwm.org, which has a patch for that problem. For object graphics,
there currently is no way to get the correct colors on fvwm when a
private colormap is needed, I currently try to get some ideas from
a former developer of RSI for a patch. As a workaround, close all
color sucking applications such as netscape, java applications etc.
until enough colors are available (do a 'print,!d.n_colors' after
launching an idl window do see how many are allocated). This will
help in most cases. But you will have no chance if the application
itself allocates a colormap with 256 entries, which always results
in a private colormap. The only way to get out of that is to start
the Xserver with 24 bit RGB color (modify /etc/XF86Config), which provides
always enough colors to avoid a private colormap, but some other
applications cannot handle that mode correctly, so expect to have to
switch back from 24 to 8 bit sometimes. I don't know if the KDE manager
does a better job on the colormaps.
--
Dr. Udo Grabowski email: udo.grabowski@imk.fzk.de
Institut f. Meteorologie und Klimaforschung II, Forschungszentrum Karslruhe
Postfach 3640, D-76021 Karlsruhe, Germany Tel: (+49) 7247 82-6026
http://www.fzk.de/imk/imk2/ame/grabowski/ Fax: " -6141
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
