Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!adobe!asente
From: asente@adobe.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: Xt shared GCs, regions and expose processing
Message-ID: <15306@adobe.UUCP>
Date: 16 May 91 16:54:30 GMT
References: <1991May16.073250.14656@melba.bby.oz.au>
Sender: news@adobe.COM
Organization: Adobe Systems Inc.
Lines: 28

In article <1991May16.073250.14656@melba.bby.oz.au> gnb@bby.oz.au (Gregory N. Bond) writes:
>
>The Xt manual states that GCs obtained via XtGetGC() "must be treated
>as read-only" (sec 11.4).  However, I have seen a couple of widgets
>that do something like this in the widget redraw routine:

	[code that temporarily changes the GC]

>It is clear that this code works, at least in my situation.  Is it
>"legal" to do so?  If not, how should complex widgets handle expose
>events if they cannot legally set the clipmask in shared GCs but still
>want to avoid flicker from a full redraw?

This falls into a gray area.  You won't get into trouble for doing it, at
least in most cases, as long as you're careful not to do anything that lets
Xt get back in control while you have changed the GC.  It will completely
hose you if you happen to be using multiple threads of control, but I suspect
if you try to multithread an Xt interface (as opposed to having the interface
controlled by one of several threads) that this will be the least of your
problems.

	-paul asente
		asente@adobe.com	...decwrl!adobe!asente

    Ratz put a bucket of liquid in front of me.
   "I wanted a glass of docs, Ratz.  What the hell is this?" I barked.
   "Motif don't fit in a glass anymore," he barked back.
    I looked at the liquid.  It was totally opaque to me.