Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbcad!ames!lll-tis!lll-lcc!pyramid!decwrl!weissman From: weissman@decwrl Newsgroups: comp.windows.x Subject: Re: X11 nuances Message-ID: <11795@decwrl.DEC.COM> Date: Fri, 9-Oct-87 00:26:09 EDT Article-I.D.: decwrl.11795 Posted: Fri Oct 9 00:26:09 1987 Date-Received: Sun, 11-Oct-87 12:45:11 EDT Sender: daemon@decwrl.DEC.COM Organization: Digital Equipment Corporation Lines: 107 Bill, Believe it or not, there are a lot of good things on the tape. It's just that some of them are hard to see... > my current list of "huh?"s after beating on x for a while, is as > follows. some may be bugs, others may be my inexperience with X11. > (real bugs have been posted in separate bug reports.) i'm running > on a Sun-3/50 (or 3/160C) under 3.4. > > 1. geometry. i would expect that specifying a geometry of =+1+1 > would blast a default size xterm in the left-hand corner. no, i > still have to hit the left mouse button to get the window. if > this isn't a bug, why is this so? > > 2. uwm. X10 uwm honors the autoselect variable (menus come up with > the first item already selected). this is documented in the X11 > uwm but does not work. is there something i am missing to get > autoselect to work, or is this a bug? Sounds like bugs to me. Frankly, less effort was spent on porting uwm than might have been, because uwm is a fairly silly window manager anyway. Much of the point of X11 is that you can write window managers with much better user interfaces than uwm's. The 'wm' program included on the tape (in the 'demos' directory) is a toy example of this better interface; what is needed is a more muture 'wm'. > 8. xterm. what's his name was right, i miss my titlebars also! Get a real window manager that provides title bars... :-) But seriously, that really is the way that title bars should be implemented: as part of the window manager. That way, you don't have to put the title bar code into every application you write... > 10. xterm. i'm depressed since the left mouse button no longer cuts > and pastes in one operation. this was a VERY valuable feature > when making (and screwing up) in-line shell scripts. the script > could be easily repeated by banging on the left mouse button a > few times, fixing the bad line, and banging on it again. the new > right mouse button has dubious functionality. Sigh. I (mostly) agree. The trade-off that was made here was to make xterm's cut&paste be more consistant with the toolkit's text window, and therefore consistant with toolkit applications (like xmh). (That's the Xt toolkit; I don't speak any of the others.) Just so you don't think everything's lost, have you noticed that if you double-click the left button, you select a word? And triple-clickin selects a line. I find this real handy, though I still miss the old left-button. I believe the original idea was that you would be able to customize your xterm's button-bindings, so you could (with a little work) get it back to the old way. I don't know if this was actually done; somehow, I doubt it. > 13. Xdefaults. my .Xdefaults contains the line: > xterm.BodyFont: vtsingle > there are blank lines and comments (beginning with #) in the > file. this file worked fine for X10. X11's xterm does not > recognize this line. what's the scoop? Sigh. This can lead to a complicated subject, one that I've always had trouble explaining in person, and have no hopes of doing at all electronically. Suffice to say that the Resource Manager that is now part of Xlib has completely re-vamped the way that .Xdefaults is parsed. It's much more powerful, but I don't think it's real well documented anywhere, though you might try looking for it in the Xlib manual. Anyway, I believe that changing this line to xterm.Font: vtsingle will work. The resource changed its name to 'Font' because that's what it's called everywhere else (e.g., the toolkit). Please note that capitalization of the left-hand side is now important... > 14. xterm. i also miss the autoraise. has it been determined that > this also should be a function of the window manager? whew, uwm > is going to be going through some growing pains. Yes, that belongs to the window manager. In general, anything that you do that affects your relationship with other windows on the display should be handled by the window manager. This includes resizing, moving, raising, lowering, iconifying, or de-iconifying your window. Fortunately, X11 provides more power for window managers than X10 did. > ho, if i got input on some these, i would be a happy camper! i am > not afraid (and i have some funding) to fix some of these problems > (but don't want to fall prey to the duplication of effort syndrome). > > --bw Hmm. Based on what I've said in this message, the most useful thing you could do is provide a good window manager for the world. That would provide some of the features you miss in xterm, and it would certainly be one way of fixing uwm complaints... - Terry weissman@decwrl.dec.com ...!decwrl!weissman P.S. This message really deserves some disclaimers: namely, this was written at night from a dial-in character cell terminal (ick), so everything's from memory. Also, any opinions expressed are my own, and I reserve the right to revoke them at any time...