wohler@SPAM.ISTC.SRI.COM (Bill Wohler) (10/08/87)
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?
3. xinit. i had gotten used to ed moy's new xinit that reads the
file .Xinit. i see that this xinit is not the one distributed
with X11. are there plans to incorporate ed's fixes? if not,
have you ported your xinit to X11 yet, ed? can i get a copy? ;-)
4. kbd_mode. the command kbd_mode is unnecessary and can be removed
from the distribution. just use sun's own "setkeys reset".
5. fonts. is there someone working on converting the sun fonts to
X11's bdf format? (ucb's X10 newfonts.) i miss screen.b.14.
6. fonts. with so many available, one would think that it would be
easy to find some that are useful for text. nope. perhaps a
survey of fonts used should be made. thus unused fonts could be
pruned, and missing fonts could be added.
7. bell. my bell worked under X10, but no longer.
8. xterm. what's his name was right, i miss my titlebars also!
9. xterm. the auto-repeat is much too slow. are there any reasons
why it should be so slow? otherwise, i'll fix it and send in the
diff. (who or what would a fast auto-repeat screw up?)
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.
11. xterm. negatory on the status line. it's documented, in the
termcap, but doesn't work for me.
12. keyboard mappings. i had gotten used to C-- mapped as C-_.
makes a quick undo in emacs.
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?
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).
--bwwohler@SPAM.ISTC.SRI.COM (Bill Wohler) (10/08/87)
forgot one thing:
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.
--bwjkh@violet.berkeley.edu (Jordan K. Hubbard) (10/08/87)
In article <8710081838.AA17204@milk1.istc.sri.com> wohler@SPAM.ISTC.SRI.COM (Bill Wohler) writes: > > 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. > ... > ... > > 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. Hear hear! I was going to bring this one up earlier, but decided to eyeball the code first. I use both X10R4 and X11 still, and frequently get the cut & paste buttons confused. Why was it changed? I never heard any complaints about the old assignments.. Eyeballing the xterm code reveals a lot of strange structures (all labeled "bogus this" and "bogus that") that *seem* to offer a selection between DEC's opinions and MIT's, but there's no really intuitive way of changing them around or selecting a particular key/button set. I looked for obvious #define's that might select a particular bogosity, but found nothing. Who is, um, responsible for the current version of xterm? Incidently, I miss my title bars too, but they really should be in the window manager. Since I like uwm, and uwm doesn't manage by reparenting (the way "wm" did), it's become a little more difficult than I thought to hack them in. Still, I think I should have something reasonable up in a little while. It also comes to mind that a little more real-estate oriented management could be added if uwm reparents and starts adding frobs to your windows. This seems to violate the "spirit" of uwm somewhat, and I'm wondering of title bars would just be a good place to stop. Any suggestions about the semantics of specifying additional frobs and their behaviour via the .uwmrc would be welcomed. The existance of title bars is currently specified for everybody with a "labels" boolean keyword. I can't think of an easy way (should it even be desirable) to label only those windows that wish it. Jordan Hubbard
weissman@decwrl (10/09/87)
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 <Religion ON:> 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'. <Religion OFF> > 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...
jg@jumbo.dec.com (Jim Gettys) (10/09/87)
Better that a window manager grow than having a mishmash of applications, some of which automatically raise themselves, and some of which don't. Hacking all those window management functions into all the applications is a much worse option....
grunwald@uiucdcsm.cs.uiuc.edu (10/09/87)
With regard to Sun fonts under X11. there is a program in util/vtobdf which translates Sun fonts to BDF format. I managed to convert most of the sun fonts, although it barfed on a few. I'll add a couple of gripes: the Apollo distribution is very hard to installed. This is primaily the fault of Apollo. + /usr/lib/cpp has great difficulty with long lines. When you do a 'make Makefiles' it will chop long lines into several lines. I eventually did the makefiles on a Sun & shipped them over + in util/imake.includes/Apllo.macros, there is a define: #define Xapollo Xapollo this should really be: #define XapolloServer Xapollo If a special versiono f CPP is being used, it'd be nice to include it in the distribution -- these aren't my Apollos & I'm not certain what rev their software is, but I know that they're not too old -- one would expect the distribution to come up on a stock system. BUT! I'm not whinning -- love them X11's. Keep up the work! Rah. Go team. (after all, they did admit it was a beta version) dirk grunwald univ. of illinois
deboor@dill.Berkeley.EDU.berkeley.edu (Adam R de Boor) (10/09/87)
> 5. fonts. is there someone working on converting the sun fonts to > X11's bdf format? (ucb's X10 newfonts.) i miss screen.b.14. > on hoser.berkeley.edu there is now source for an X10 client called x11font (berkeley/x11font.c) that will take the name of an X10 font and print out a bdf file for the font. You then have to compile it and x11font has to be run on a B&W X10 display... > 7. bell. my bell worked under X10, but no longer. > Sun's working on this. A guy here at berkeley implemented it and I sent the fixes to Sun... > 9. xterm. the auto-repeat is much too slow. are there any reasons > why it should be so slow? otherwise, i'll fix it and send in the > diff. (who or what would a fast auto-repeat screw up?) > Go to the file ddx/sun/sun.h and change the constant AUTOREPEAT_DELAY to be 20. > 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? > Xterm now uses the resource manager, which is case sensitive. I'd advise that you go into vi and type something like :%s/\.\([^.:]*\)\([ ]*\):/.\l\1\2:/ to lower the first character of every default. Assuming you also capitalized each word in the default name, you should be fine... a
guy%gorodish@Sun.COM (Guy Harris) (10/10/87)
> > 7. bell. my bell worked under X10, but no longer. > > > Sun's working on this. A guy here at berkeley implemented it and I sent the > fixes to Sun... I hope it uses the KIOCCMD "ioctl" with the KBD_CMD_BELL and KBD_CMD_NOBELL commands; the "/dev/bell" hack is not the correct way to ring the bell, it is not the official way to ring the bell, and there is no guarantee that it will not work in future releases or with future hardware. The KIOCCMD "ioctl" is even documented in the KB(4S) manual page. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com