Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!ames!lll-winken!casey@gauss.llnl.gov
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.windows.x
Subject: Re: mit/lib/Xaw/Imakefile and -DSHAPE: Command and Mailbox widgets
Message-ID: <61758@lll-winken.LLNL.GOV>
Date: 15 Jun 90 16:54:32 GMT
References: <61674@lll-winken.LLNL.GOV> <9006142254.AA09153@expire.lcs.mit.edu>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@gauss.llnl.gov (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 26

|From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
| 
| [Your From: address is completely useless:
gauss.llnl.gov@lll-winken.llnl.gov]

  [Thanks.  I'll ask Pnews what it thinks it's doing ...]

|   Fundamentally, what I'm asking is: why bother with SHAPE ifdef's at all?
| 
| There isn't really a good reason any more.  When we were first developing the
| SHAPE extension and experimenting with it, we weren't positive it would make
| it as an X Consortium standard (either in time for R4 or at all), so we put
| most of the code in with #ifdefs to make it easier to remove.  The #ifdefs
| should go away in the next release.

  Thanks for the clarification.  Is there any possibility that this could be
included in the next official fix from MIT?  We'd like to be able to distribute
some software that subclasses the Command widget and it's pretty silly for our
Imakefile to contain a ``DEFINES = -DSHAPE'' when none of our code uses it and
it's undocumented.  On the other hand, if we rip the ifdef's out of CommandP.h
and MailboxP.h ourselves, then our code will mysteriously work on our systems,
but not on anyone elses.  Granted, if it were fixed in, say, fix-12 then we'd
still have to include a note about the need for -DSHAPE for X11R4 not
patched up
to fix-12, but at least we could give people definite instructions about when
and why they needed -DSHAPE ...