argv%turnpike@Sun.COM (Dan Heller) (11/04/89)
In article <2043@bacchus.dec.com> klee@decwrl.dec.com writes: > In article <4404@cs.yale.edu>, gropp-bill@CS.Yale.EDU (Bill Gropp) writes: > > The application will not accept input > ... for a client to be ICCCM compliant and > work properly with ICCCM compliant window managers, you must set > XtNinput to True on top level shells that expect input. As I understand it, the "default behaviour", which is currently False, is changing to True, so toolkits written -after- R4 do not need to worry about this as they did in R3. Can someone please substantiate this? I've only heard the proposal -- not the resolution. > This is probably the second most commonly asked X programming > question. And of course, everyone is wondering -- what's *the* most commonly asked question? The noimnees are: - I create a window and draw into it, but nothing appears. (you need to map it first -- wait for Expose events) - I draw in a pixmap or window and it works on my monochrome screen, but not my color one? (don't use '1' and '0' in XGCValues.foreground/background) - I draw in a 1-bit pixmap or window and I get <various garbage/errors> (NOW use '1' and '0' in your GC --don't assume BlackPixel() and WhitePixel() equal 1 and 0) - Can someone send me a postscript previewer for X? (probably not, but they are available via ftp and automatic email servers from uunet and expo.) dan
swick@ATHENA.MIT.EDU (Ralph R. Swick) (11/07/89)
>> ...you must set >> XtNinput to True on top level shells that expect input. > As I understand it, the "default behaviour", which is currently False, > is changing to True, so toolkits written -after- R4 do not need to worry about this as they did in R3. No decision has yet been reached, so I wouldn't rely upon such a change being adopted. In any case, widget sets have always had the option to change their own default. (That's one reason why people are getting into trouble, too :-).