Bugzilla Bug   1381

If I use XFT fonts, the insensitive buttons or text fields
are not drawn at all. This makes it rather unusable.
With normal fonts, the text is stippled with a 2x2 check,
which was fine in 1990, with black and white X servers.
Nowadays, it is nonsense, especially with AA fonts.
The easy way to do the "right thing" is to draw a lighter
etched in text instead of the bitmap overlap, which is
both ugly and not readable on thin fonts.
The etched in version can be drawn simply by drawing the
text twice with a sligthly lighter colors and small x+1, y+1 offset.
Usually, insensitive buttons or text fields must still be
readable, even if user can not interact with them.
One example of fixing this was xmLabelHack by bj John L. Cwikla,
and this approach is used in ddd. But xmLabelHack works just
on labels, proper solution whould also work on XmTextField.
Since XmNsensitive property is completely broken with AA
fonts, it would be now a good opportunity to correct it in
all cases.
I am using OpenSuse 10.2 with OM 2.3beta
I did not see any relevant changes in CVS with respect to the final OM 2.3

With the modifications done in Label.c (revision 1.13) and in LabelG.c (revision
1.11 and 1.13), the bug is still there.
The text of insensitive widgets and gadgets is not displayed if using FONT_IS_XFT.

Fixed. Now all insensitive widgets are gray.

The fix for this bug is ifdef'ed in the source files. Is this
correct?

Yes, you are right

*** Bug 1360 has been marked as a duplicate of this bug. ***

This patch is causing a crash in graphics program Grace-5.1.21 (latest).
I have been using 2.3.0 with many of the patches applied. I have pulled
the latest 2_3 branch which is tagged to be version 2.3.1 and started 
getting a crash whenever I tried to modify an axis value. Making a lengthy
diff between what I was using and what was in 2.3.1 the only new thing
was patch for bug 1381 and the XSETTINS_ON stuff. I just removed the definition
of 1381 and recompiled and crash stopped. The crash message was non-descriptive
but had to do with XChangeGC (56)...seemed like it was coming from X11 error
file /usr/share/X11/XErrorDB. Everything is compiled on Fedora 8:

========================================================================
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  56 (X_ChangeGC)
  Value in failed request:  0x9
  Serial number of failed request:  16925
  Current serial number in output stream:  16958
=====================================================

When I try to run gdb the program does not crash but gives the error
messages:

Ignoring Xlib error: error code 2 request code 56
Ignoring Xlib error: error code 2 request code 56
Ignoring Xlib error: error code 2 request code 56
Ignoring Xlib error: error code 2 request code 56

I investigated this a bit more. I could only find a crash in the case of
grace-5.1.21, which is a very mature program. I have compiled a debug
package for openmotif 2.3.1 and ran it using valgrind. Here are the calls
made right before the crash:
===========================================================================
==3024== Conditional jump or move depends on uninitialised value(s)
==3024==    at 0x3215020BAC: _XUpdateGCCache (in /usr/lib64/libX11.so.6.2.0)
==3024==    by 0x321501E53A: XChangeGC (in /usr/lib64/libX11.so.6.2.0)
==3024==    by 0x4D5F306: SetNormGC (TextOut.c:640)
==3024==    by 0x4D64CDB: Draw (TextOut.c:2951)
==3024==    by 0x4D4E249: DisplayText (Text.c:912)
==3024==    by 0x4D4E36A: RedrawChanges (Text.c:952)
==3024==    by 0x4D4E6A6: Redisplay (Text.c:1836)
==3024==    by 0x4D510F7: _XmTextEnableRedisplay (Text.c:2951)
==3024==    by 0x4D6D849: Replace (TextStrSo.c:1089)
==3024==    by 0x4D6B9E4: _XmStringSourceSetValue (TextStrSo.c:1706)
==3024==    by 0x4D5203A: _XmTextSetString (Text.c:2850)
==3024==    by 0x4D5220A: XmTextSetString (Text.c:3976)
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  56 (X_ChangeGC)
  Value in failed request:  0x9
  Serial number of failed request:  17052
  Current serial number in output stream:  17085
==========================================================================

Ignore the uninitialised value comment. What is interesting are the last
two places in TextOut.c (I think, I am not an expert). Specially, line
2951 of TextOut.c, which is:
      if (stipple) SetNormGC(tw, data->gc, True, !stipple);
called from line 640 (around a FIX_1381 ifdef):
      XChangeGC(XtDisplay(tw), gc, valueMask, &values);

I could not get any other motif dependent program get into line 2951. So, may
be someone who knows this stuff can see something.
Hope this helps, Thanks.

I have been playing around with this a bit more:

In TextOut.c, in the structure for ifdef FIX_1381 aound line 638,
when if(stipple) is true no value for fill_style is set. If I add
the a line "values.fill_style = FillSolid;" before if(stipple)
then xmgrace no longer crashes.

Same is true for TextF.c block around line 1962.

All other relevant places values.fill_style seems to be defined.

Am I onto something? I really would like to fix this before 2.3.1 since
xmgrace is one of our main programs to use.
Thanks

Created an attachment (id=156)
This fixes the crash in grace

Hi, looks like this fix leads to problems with XmMultiLists.

See <http://bugs.gentoo.org/215984> for details and for a test program.

Well, I am not a C programmer and the crude fix avoids the
reproducible crash in grace (grace is unusable without this
little fix). Alternatively, I can just turn off the fix for
1381 altogether.

This seems like someone who knows about the original fix to
bug #1381 needs to consider these two cases and see what is
wrong with the original patch.

I've investigated a little more; if I undo the following change:
<http://openmotif.cvs.sourceforge.net/openmotif/openmotif/lib/Xm/I18List.c?r1=1.21&r2=1.21.2.1>
then the problem with the grey items in XmMultiLists goes away. Tested with the
"ext18list" program from the demos.

Is this with the small fix for grace or without?

> Is this with the small fix for grace or without?

The XmMultiList issue is independent of the fix for grace. (I've just verified
it with all four possibilities.)

I see that we are getting close to 2.3.1. It would be nice to fix/confirm
my fix to prevent grace from crashing. As you can see it may be actually
crashing Xt but the little patch fixes it (on Fedora 8 + updates). If this
is nonsense we need a better fix for this.
Thanks

The crash with Grace was also seen with 2.3.1 in Gentoo Linux, see
<http://bugs.gentoo.org/232742>.

The patch attached here by S. Umar fixes the problem, and I have now included it
in the Gentoo package, x11-libs/openmotif-2.3.1-r1.

The fix, in its current form, is far from usable/complete, therefore I ask to
either revert it or at least #undef FIX_1381 by default. Here are the issues:

1. valueMask |= GCFillStyle is defined but values.fill_style is not set (fixed
by the patch by S. Umar but still not committed to CVS)
2. The grayish color used for insensitive labels is chosen with no regard to the
actual foreground/background of the text. So e.g. a red text becomes gray anyway
instead of something like reddish. On the other hand, text of any color becomes
absolutely invisible on a gray background.
3. The treatment is inconsistent with rest of widgets, which are still displayed
stippled when insensitive.
 

Of course you should add the fact that the fix I suggested was pretty
much random. I knew that was the reason for crashing grace but I have
no idea what the correct value of values.fill_style should be!

Umar: I believe it should be FillSolid as this seems to be the idea of FIX_1381
(to change the foreground instead of making it stippled). But in this case it
probably never visually matters since the stipple bitmap is nil and stippling is
not applied anyway.

Fixed. Umar, your patch is correct and included into coming 2.3.1 and in 2.4.0
head (CVS). 

But for other widgets which are still displayed stippled when insensitive
'FillSolid' will be added in feature OM release as it is feature request (1448).

---
On the other hand, text of any color becomes
absolutely invisible on a gray background.
---

When widget background color is same as sensitive used darker color.

Created a bugzilla record for requested enhancements
http://bugs.motifzone.net/show_bug.cgi?id=1448.

Toggle Button: "defmissle_malf301"
Background: "grey70"
Foreground: "black"

Note: You'll likely find that the gray hue assigned to "insensitive"
labels is different than our background. Given this fact, you may
conclude that labels should stand out. While this may be true on a
high-resolution console, it does not hold true for us. No one uses the
console of our development host on which UIM/X is installed. It is
headless. We access X sessions via XDMCP, connecting with VNC. These
sessions do not have sufficient color depth to render the two gray hues
differently. They are indistinguishable from each other

*** Bug 1453 has been marked as a duplicate of this bug. ***

Created an attachment (id=245)
This patch changes text style for insensitive widgets from stippled to grey colored.

Fixed with previous patch in CVS HEAD and openmotif_2_3 branches.