frodek@forit.forut.no (Frode Kileng) (01/11/91)
I'm writing a program based on Xlib and during testing under the Openwin environment and X11R4 I have noticed a difference in the event handling. An event mask of: ButtonMotionMask|PointerMotionHintMask in a program compiled and linked width Openwindows2 and X11R4 results in a different set of events sent from the server. X11R4 gives the behavior described in O'Reily's Xlib programming manual in that motion events is sent by the server only when a pointer button is pressed. With Openwin the server sends motion events regardless of the state of the buttons. What is supposed to be correct ? Frode Kileng Frode.Kileng@fbt.tf.tele.no | frodek@forit.forut.no
dvb@emisle.uucp (David Van Beveren) (01/13/91)
In article <1991Jan11.151834.9803@hod.uit.no> frodek@forit.forut.no (Frode Kileng) writes: >I'm writing a program based on Xlib and during testing under >the Openwin environment and X11R4 I have noticed a difference >in the event handling. > >An event mask of: ButtonMotionMask|PointerMotionHintMask in >a program compiled and linked width Openwindows2 and X11R4 results >in a different set of events sent from the server. > >X11R4 gives the behavior described in O'Reily's Xlib programming >manual in that motion events is sent by the server only when >a pointer button is pressed. > >With Openwin the server sends motion events regardless >of the state of the buttons. > >What is supposed to be correct ? > I have been developing a product that runs under Motif 1.1 and X11R4, for Sun targets, as well as HP-UX and Ultrix targets. The sun requirement says we must run under OpenWindows as well (NeWS, OLWM, etc.) This has turned into a major headache, as there are several annoyances present only under the Openwin environment. Example. The arrow keys are translated to move the cursor up or down, or left or right in the (Motif) Text widget. However, you need to add translations and callbacks to do this yourself under openwin, since the KeyPress events are not getting through to the client. This means that a motif program, that uses XmText widgets, has no cursor movement via arrows under openwin. Example: I have a large (8 meg a.out file) product. X is a large portion of that product. I added a new widget, and suddenly got a BadAlloc error during initialization, under openwin. I ran the same product with just the X server and twm, and got no such error. NeWS takes up lots of resource space. not to mention memory. Example. I change the title on a number of dialog window frames. Under olwm, the titles are WAY off to the right, in fact they are not visible unless you make the window real big. While sun EXPLICITLY does not support Motif, I have a program that will demonstrate this little bug, using only X and Xt calls. Best Part: This was not always the case. I used OpenWin 1.0 and 2.0Beta, and this never occured. With the change to 2.0 from beta, this began happening. At first, I didn't notice, since the resize corners and the title had disappeared altogether with the 2.0 release, but I managed to get them back using (improperly) documented properties found around page 70 of the OLIT programmers guide. In short, openwin is not X in the same way that most X products are. They do not support Motif, and their extra layers take up space, make the system run slower and generally degrade from the common product. Once upon a time, different corporations made a big mistake when they began developing their own versions of unix. MIT has released a well-designed product, and OSF had developed a superior toolkit. Why don't we make life easy on ourselves and agree on a standard? med Hilsen, David Van Beveren INTERNET: emisle!dvb@ism.isc.com EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb voice: (818) 587-1247
mel@cbnewsh.att.com (mel.haas) (01/13/91)
We run vanilla MIT X (up to fix 18) and vanilla OpenWindows 2.0 on SunOS 4.0.3e and 4.1.1 SPARCstations. Users who must also run SunView applications use OpenWindows, the rest MIT X (which is faster and smoother). We are having lots of trouble with a very popular program 'xfig' (release 9 from expo.lcs.mit.edu). It works fine with MIT X, but often just dies under Open Windows with no clue as to what happened. And, the rubber-banding is 1/16" off SE from the center of the mouse curser (the resulting end point is on center, 1/16" NW of the rubber-band end point). I rebuilt 'xfig' with the Open Windows libraries with identical problems. Does anyone have patches to 'xfig' to avoid these problems? Or advice on how to go about tracking them down? Thanks, Mel Haas , mel_haas@att.com or att!hotld!mel