rbd@lamont.Columbia.edu (roger davis) (01/23/88)
I am a newcomer to X, having just recently installed X11 on a network consisting mainly of Suns running SunOS 3.4, and would greatly appreciate any information which any one could provide on the following three (unrelated) questions. (1) Vi seems to have trouble in xterm with lines which are longer than the window width. It wraps them around but inserts a blank line in the middle, causing the contents of the remainder of the window to be inaccurate. I've installed the termcap entry which was provided on the release tape. (2) I like the functionality and flexibility of uwm, but as an applications programmer am concerned with the possibility of users causing events which a particular program may look for to be intercepted by uwm and interpreted according to their .uwmrc file. It seems a great pity to (a) waste the programmabilty of uwm by distributing a site-wide .uwmrc file and forbidding all of our users to change it and (b) proscribe the use of certain mouse/keyboard combinations by applications -- what I would like to see is a uwm that only grabs events occurring within a namestripe or border and leaves everything else alone. Is there a window manager similar to uwm out there that does this now? Does anyone know if Sun is planning to distribute such a product with their X release? (3) There was some discussion at the recent X conference regarding the portability of toolkits. My (very limited) understanding of toolkit philosophy is that the toolkit is built directly on top of Xlib. Aside from the usual C portability issues, if a particular box has a properly implemented server and a working Xlib, why should there be any problem? Am I just being incredibly naive about this? In particular, why is the current Xtk broken on Suns -- or is it my server that's broken?
mdb@silvlis.UUCP (Mark D. Baushke) (01/24/88)
> Date: 22 Jan 88 20:30:55 GMT > From: sun!husc6.harvard.edu!linus!philabs!lamont!rbd (roger davis) > Subject: xterm/uwm/toolkit questions > > (1) Vi seems to have trouble in xterm with lines which are longer than > the window width. It wraps them around but inserts a blank line in the > middle, causing the contents of the remainder of the window to be > inaccurate. I've installed the termcap entry which was provided on the > release tape. Sorry, I am unable to help you with this problem. (I have not observed it.) [Unsolicited Testimonial: I use GNU Emacs with some patches to make it run in its own window under X11. These patches will hopefully be shipped with the 18.50 version of GNU Emacs (due very soon). It works great! My productivity is MUCH higher using Emacs than using vi. If you do not know anyone to get a copy of GNU Emacs from, you can order a tape from the Free Software Foundation. They ship it either on a 1600bpi standard mag tape in tar format or on 1/4" Sun cartridge tapes in tar format. If you have Internet access, you can copy the latest Emacs distribution from host prep.ai.mit.edu. Start by FTPing the file '/u2/emacs/etc/FTP'. -- end of Testimonial] > (2) I like the functionality and flexibility of uwm, but as an > applications programmer am concerned with the possibility of users > causing events which a particular program may look for to be > intercepted by uwm and interpreted according to their .uwmrc file. > It seems a great pity to (a) waste the programmabilty of uwm by > distributing a site-wide .uwmrc file and forbidding all of our > users to change it and (b) proscribe the use of certain > mouse/keyboard combinations by applications -- what I would like to > see is a uwm that only grabs events occurring within a namestripe > or border and leaves everything else alone. Is there a window > manager similar to uwm out there that does this now? Does anyone > know if Sun is planning to distribute such a product with their X > release? There is at least one other window manager, try 'wm'. I am fairly certain that more will be released with X11R2. If an application really needs some of the event combinations being masked by uwm in order to work properly, just let folks know what it needs and tell them that if they write a .uwmrc that intercepts these special combinations that the application will not work properly. If this is a large problem, I would suggest sending a .uwmrc that is guarenteed to work with the application. Another (probably the best) solution would be to write your own window manager (or adapt an existing one) that does its thing in the way that you want. As far as I know, Sun is not planning on an "X Window System Release". I think that they are planning on a NeWS release followed by a merged NeWS/X11 release. I have no idea what window managers they plan to provide. > (3) There was some discussion at the recent X conference regarding the > portability of toolkits. My (very limited) understanding of toolkit > philosophy is that the toolkit is built directly on top of Xlib. > Aside from the usual C portability issues, if a particular box has a > properly implemented server and a working Xlib, why should there be > any problem? Am I just being incredibly naive about this? In particular, > why is the current Xtk broken on Suns -- or is it my server that's broken? If you have not yet done so, you should apply all of the available patches (through 94?). This will hopefully fix any problem you might have observed with a broken sun server. As near as I can tell the toolkit suffers from the lag in the resource manager version (it uses the oldXrm which is an older incarnation of Xrm and has different calling sequences and arguments than the Xrm library). I have been playing around trying to understand what the toolkit does and how. (Note: I also work on a Sun running SunOS 3.4.) Some things to keep in mind when using Xtk: A) You need to load oldXrm instead of Xrm. This means that anything in your application will be forced to use oldXrm instead of Xrm. (I also suspect that there are some Xlib routines which have calls to the new Xrm routines (XGetDefault() perhaps?), those Xlib functions will probably be broken.) B) On a sun, there is a bug in DispatchEvent (Event.c version 1.15). The nature of the bug is attempting to walk through a NULL pointer (grabList). Walking through NULL pointers works on vaxen, but not on suns. The work around for programs such as xbiff, is that the main program should call "XtSetSensitive()" with "True" to make the widget sensitive and thus avoid the NULL grabList code. C) I have not been able to get XGetValues() to work. To be fair, I have not worked very hard at it yet and I might not understand all of how the 'XrmOptionDescRec' arg to XtIinitialize() has to be set up. What other kinds of Xtk problems have you been finding? I would be very interested in hearing your comments and observations (but please e-mail to be directly instead of the the entire list). I am evaluating the pseudo-object-oriented approach used in Xtk (hopefully it will be cleaned up and improved for release X11R2) for use in a new project we are about to start working on here. In my opinion, most "real" projects should probably wait until X11R2 arrives before going full blast with Xtk and/or Xrm. Mark Baushke silvlis!mdb@sun.com