🚀 go-pugleaf

In a prior article persico@orestes.sysdev.dmg.ml.com (Matthew Persico) wrote:
  > In article <ALSAGGAF.93Jan13171926@e40-008-4.mit.edu>,
  > ed.duomo@launchpad.unc.edu writes:|>
  > |> [detailed explanation removed...]
  > |>
  > |> So there you have it, gentile Xperts: is there a way of changing the
  > |>background of a pixmap after it has been created?

  > |>
  > I'd like to ask a related question:  I have wrapped Motif message dialogs
  > in a set of "convenience functions" that allow me to reuse these widgets
  > instead of creating and destroying them. I have discovered that
  > if I try to change the background color of dialog after creation, the 
  > background color of the symbol doesn't change. ...

	[code to alter XmNbackground omitted]

  > If I do this, then the foregound and background come up with 
  > the correct colors, but the pixmap background and foregound don't
  > match the dialog's values.  I guess there is some other value I need to
  > set, but I can;t find it in O'Reilly Volume 6 or the OSF liturature.
  > Any answers out there?

Well, we just went thru this discussion over in comp.windows.x.motif,
except that the relevant widget was the Label widget or derived classes
like "PushButton", where we wanted to alter the labelPixmap.

The answer basically is "you can't do it right now".
The problem is that the symbols are Pixmaps which just happen to be
initially generated from bitmaps using the foreground and background
color, but once they are created they remain intact.

For most cases this makes sense.  If you had installed your own multi-color
pixmap, you certainly wouldn't want the widget suddenly altering some
pixels in the pixmap just because they happened to coincide with the 
widget's foreground or background colors.

The problem is that we really want to distinguish two separate cases:
  1)  An image which is a bitmap, and which always is displayed using
      the current fg/bg colors; and
  2)  An image which is a pixmap (even if initially derived from a bitmap),
      always displayed using its own colors.

Basically, case 1 needs to retain a 1-plane image and refresh the image
using a routine like XCopyPlane().  Case 2 requires generating a pixmap
and refreshing it using a routine like XCopyArea(), without regard as to
the number of bitplanes the image is composed of.

Sounds like an enhancement request to me ... 

	--mark

+--------------------------------------------------------+------- /// -----+
| Mark Lanzo   KD4QLZ   lanzo@tekelec.com   919-460-5576 |    \\\///       |
+--------------------------------------------------------+---- \XX/ -------+