Best visualID didn't work in CDE
Brought to you by:
tringali
Menu
▾
▴
#8 Best visualID didn't work in CDE
When running NEdit 5.2DEV in Solaris/CDE, the menu, scrollbars, and
dialogs have completely BLACK foregrounds and backgrounds, making them
unreadable. Only the main text area is normal.
This fixed the black backgrounds:
nedit -xrm "*visualID: Default"
The "Best" visualID did not work in my case. The colors that went black
were all dynamic colors from the CDE desktop palette. Switching palettes
from the CDE Style Manager dynamically changes these colors on all
applications except NEdit, unless the visualID is set to "Default".
"Best" is the default; but "Default" is best (at least for CDE). :-)
Changed group to development. Problem only in dev version.
Logged In: YES
user_id=11321
Is CDE doing something funky like preallocating writeable
colors, and jamming them into the resource database? Can
you send a dump of "appres nedit" ?
Logged In: YES
user_id=145435
The only relevant resources returned by "appres nedit" are:
*0*ColorPalette: Olive.dp
*enableToggleColor: True
*enableCDEColorFactors: True
*enableToggleVisual: True
*XmMenuReduceGrabs: True
*background: #C300C300B900
*foreground: #000000000000
Logged In: YES
user_id=15180
High priority (>5) and not addressed? Wasn't there a patch?
Logged In: YES
user_id=15180
Will time out unless it gets updated.
Logged In: YES
user_id=145435
I just built the official 5.2 release for Solaris 2.6/CDE,
and experienced the same problem and solution (visualID:
Default). Don't remember seeing this problem in several
development versions of NEdit, but it is still here.
Logged In: YES
user_id=11321
Try this:
nedit -xrm '*useColorObj: False'
and let me know what happens. (Changed group to "release"
as this is out in the field now.)
Logged In: YES
user_id=145435
Results for NEdit 5.2 and Solaris/CDE:
Built on: Solaris, Sparc, Forte C
Built at: Nov 29 2001, 18:38:10
With Motif: 1002 [@(#)OSF/Motif Version 1.2.6]
Running Motif: 1002
Server: Sun Microsystems, Inc. 3600
Primary text editing pane is normal in all cases below.
Using "visualID: Default" still looks the best, with the
exception of selecting help text.
1) nedit
Menus, scrollbars, dialogs, text entry panes, buttons, etc
always have completely BLACK foregrounds and backgrounds.
Help text is readable (black on light gray background),
and help text selections are visible (medium gray).
2) nedit -xrm '*visualID: Default'
Menus, scrollbars, dialogs, text entry panes, buttons, etc
all use the CDE color palette dynamically (they change
immediately when the CDE color scheme changes).
Help text is readable (black on light gray background),
but help text selections are NOT visible (same color as
background).
3) nedit -xrm '*useColorObj: False'
Menus, scrollbars, dialogs, buttons, etc all use the
CDE color palette STATICALLY. (They do NOT change when
the CDE color scheme changes). ALL text panes in dialogs,
the statistics line, and the incremental search line have
gray backgrounds with black text.
Help text is readable (black on light gray background),
and help text selections are visible (medium gray).
Logged In: YES
user_id=11321
Good, we're making progress. First, here's my opinion on
the matter:
- We really need to avoid the black on black situation in
the default configuration. That's the main goal here.
- Getting readable colors by default is far more
important than getting the CDE dynamic colors.
After researching a bit (thank you Google groups), here's
what I take of it:
CDE sticks the dynamic pixel colors into the database, so
that the color manager can change colors on-the-fly.
However, the problem is it ONLY works with 8-bit visuals.
Basically CDE screws up the color resources for non-default
visual apps! You can't have the dynamic colors if your app
wants a deeper visual.
There appears to be a legal API for querying the dynamic
colors, and at least getting a _copy_ of them. This way, I
think, the colors will be the same as the color manager
provides, even if it doesn't change dynamically. But,
these APIs appear to only be in Motif 2.0 or 2.1, and
poorly documented at that. (My experience with new 2.x
features is that they're buggy and terribly documented all
around.)
So, the choices we have are:
1) Change the default visual ID to "default" everywhere.
Good, but that means folks will never get the deep color
support just because one platform does stinky things.
2) Change the default visual ID to "default" just on
Solaris/CDE. I don't know a way to reliably detect this.
3) Turn off 'useColorObj' globally. We lose the nice
dynamic-color feature in some places, but it's a good
tradeoff to avoid the black on black syndrome.
4) We turn off 'useColorObj' only when the visual is not
the default. This seems like the best bet, but I don't
know of its feasability.
Logged In: YES
user_id=145435
The test results I posted today were tainted by a sticky
app-defaults file from a previous version of NEdit.
Sorry about that. I will test it again next year. :-)
Logged In: YES
user_id=145435
The color results I previously reported happen when the
app-defaults
file is non-existent, or an old version. In those
instances, the
menu font was larger like in 5.0.2.
I created my own app-defaults file from nedit.c, and that
cured the
blackout problem. This is strange, since I would expect the
same
behavior as using no app-defaults file. However, the new
app-defaults
file replaces all dynamic menu background colors with plain
grey. NEdit
looks the same whether I use visualID: Default, useColorObj:
True, or none.
Also, after stripping the "nedit" from the beginning of the
lines of my
hand-made app-defaults file, the blackout problem returned.
Hope this helps. Let me know if want the app-defaults file
I created.
-- Chris R.
P.S. What is the benefit of deep color visual support?
It doesn't seem that NEdit uses too many colors.
Logged In: YES
user_id=145435
This bug still exists in 5.3. Looking back at Scott
Tringali's suggested solutions from 12/28/2001, the
best option (in my opinion) is:
Change the default visual ID to "Default" just on
Solaris/CDE.
A supplementary solution is:
Turn off 'useColorObj' only when the visual is not
the default.
We could implement both options, but I would still
prefer a Default visual ID for Solaris/CDE, so that
CDE's dynamic colors may be used.
Does anyone know how to detect CDE when compiling?
There must be a Motif #define somewhere...
Logged In: YES
user_id=145435
Retraction: this bug seems to have been fixed in the final
5.2 release, and does NOT occur in the 5.3 release. A
sticky 5.0.2 app-defaults file was giving me bogus results
(again!).
However, CDE's dynamic color palette was sacrificed by
using only a grey background for menus, window panes,
scrollbars, etc. Is there a way to restore this?
See bug #544053: "NEdit doesn't use CDE palette".
Logged In: YES
user_id=11321
Closed in favor of 544053.