casey@gauss.llnl.gov (Casey Leedom) (06/15/90)
Why do the Xaw Command and Mailbox widgets depend on a definition of SHAPE? The lib/Xaw/Imakefile adds -DSHAPE to the make macro DEFINES, so they compile correctly in the source tree. However, when <X11/Xaw/CommandP.h> or <X11/Xaw/MailboxP.h> are included by client software, say to subclass the Command widget, SHAPE isn't typically defined. I have a friend who just spent an entire day trying to figure out why his subclass of the Command widget wasn't working. Fundamentally, what I'm asking is: why bother with SHAPE ifdef's at all? I know for a fact that a client that uses the Command widget which has been compiled with SHAPE defined will work against an R3 server (without of course the shaped buttons, etc.) The same goes for the Mailbox widget. So why do they need to have SHAPE ifdef's at all??? At the very least, if it's absolutely necessary to use SHAPE ifdef's for some reason, then SHAPE should be defined in some header file that one can't get by without including, say <X11/X.h> or <X11/Xlib.h>. Would someone enlighten me on the issues here? Thanks for your time. Casey
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (06/15/90)
[Your From: address is completely useless: gauss.llnl.gov@lll-winken.llnl.gov]
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.casey@gauss.llnl.gov (Casey Leedom) (06/15/90)
|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 ...
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (06/16/90)
Is there any possibility that this could be
included in the next official fix from MIT?
Not really. It's way down in the noise in terms of importance, and our
source pool has long since deviated considerably from the state corresponding
to public fixes.casey@GAUSS.LLNL.GOV (Casey Leedom) (06/16/90)
| From: rws@expo.lcs.mit.edu (Bob Scheifler) | | Is there any possibility that this could be included in the next | official fix from MIT? | | Not really. It's way down in the noise in terms of importance, and our | source pool has long since deviated considerably from the state | corresponding to public fixes. Thanks. I understand. We'll just tell our people that they need to include -DSHAPE for X11R4 -- fixed in R5.