Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucsd!ucbvax!bloom-beacon!ATHENA.MIT.EDU!swick
From: swick@ATHENA.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: Re: Drawing in widgets
Message-ID: <8902031443.AA03349@LYRE.MIT.EDU>
Date: 3 Feb 89 14:43:52 GMT
References: <8902022240.AA00623@thelake.cray.com>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: DEC/MIT Project Athena
Lines: 25

> So the question arose, which widgets can be drawn in with
> Xlib calls, and which can't?

Widgets that are intended to be used for client drawing purposes
should be so documented.  In general, a widget does not have to
guarantee that any (or all) of the window returned by XtWindow()
can be manipulated in any way by clients other than by the Xt
interfaces (for configuring it) or by class-specific methods.
Of course, the widget itself knows exactly what's going on and
is free to use any Xlib calls it wants, (within the constraints
of the Xt geometry management architecture).

In the case of the Xaw Viewport widget, the window returned by
XtWindow() is completely occluded by subwindows managed by
the Viewport private methods, thus your inability to see what
you tried to draw.  Viewport could offer you an interface to
retrieve the visible window, however it's semantics aren't
really intended to be the DrawingSurface widget.

If you are trying to write a better widget that has prettier
graphics, then the correct approach is to subclass the existing
widget & replace the expose method.  If you are trying to do
other hackery, then you'll have to consult the documentation
(or the code :-) for the particular widget implementation to
see what might be "supported" by that widget.