drg@csri.toronto.EDU (Dave Galloway) (05/02/88)
I've used X10.4 for a while. We now have X11.2 up, so I decided to spend a day switching over to it. Many things work better, but I noticed a few things that are still broken or have gotten worse. This is all on a SUN 3/50, using twm as the window manager: 1) Now that the window manager gets involved in every change of input focus, the window manager has to be in memory. If it gets swapped out (like 50% of the time), then moving the curser from one window to the next doesn't do anything for about 5 seconds. This means that you can move your hand to the mouse, move the curser, move your hand back to the keyboard and type an entire command into the wrong window. This is both annoying and dangerous. I can't think of a way around it. It would help if change of input focus was more obvious. One way to do this is to change xterm back to the X10 behaviour of changing the block cursor from filled to hollow when the window loses input focus. X11 xterm only does this when there is no title bar. However, people look at the cursor when typing, not the title bar. 2) Xterm's smooth scrolling is useless (too slow). Even the jump scrolling seems slower than X10 to me. 3) Xsun's keyboard auto-repeat is far too jumpy. Keys start to repeat after only 200 ms. This makes "more" really hard to use, as you often get several spaces when you only wanted one. Xsun needs to have a more reasonable default, and it needs to take an argument to set the speed to whatever you like. Xterm is also guilty here, since it doesn't let you turn autorepeat off from .Xdefaults. The only way to turn it off is to use the xterm menu in each window, or to send a escape sequence to it. 4) Xterm's understanding of geometry specifications for icons broke between X10 and X11. You used to be able to say: xterm -i =+180+290 '#-3+200' & to get an icon that was 3 pixels from the right edge of the screen. Now it puts the left edge of the icon 3 pixels from the right of the screen, which is not useful. 5) Xterm still doesn't understand that visualBell and audibleBell are orthogonal concepts. The "correct" behaviour is to both beep and flash the window that is beeping, and you can't get this in X11 xterm.
guido@cwi.nl (Guido van Rossum) (05/03/88)
In article <8805021554.AA06237@blandings.csri.toronto.edu> drg@csri.toronto.EDU (Dave Galloway) writes: >[...] It would help if change of input focus >was more obvious. One way to do this is to change xterm back to the X10 >behaviour of changing the block cursor from filled to hollow when the >window loses input focus. I have also noticed this but believe it is a bug in twm. Twm 2.7 still has this. It is a very nice program but it doesn't do everything a window manager should do. >X11 xterm only does this when there is no title bar. You surely mean when using uwm or no window manager. Perhaps you should revert to using uwm for a while, then go to twm, you'll be happy with it even though it's buggy. >Xterm is also guilty here, since it doesn't let you turn autorepeat off >from .Xdefaults. The only way to turn it off is to use the xterm menu in >each window, or to send a escape sequence to it. Huh? It should be possible to turn off autorepeat with 'xset -r', unless the manual for xset lies. >4) Xterm's understanding of geometry specifications for icons broke between >X10 and X11. You used to be able to say: > > xterm -i =+180+290 '#-3+200' & > >to get an icon that was 3 pixels from the right edge of the screen. Now >it puts the left edge of the icon 3 pixels from the right of the screen, >which is not useful. I believe this might also be a twm bug. BTW, you are using old style geometry specifications; you should say '-geometry +180+290'. Unfortunately I believe the Toolkit has no -icongeometry option. -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@piring.cwi.nl or mcvax!piring!guido or guido%piring.cwi.nl@uunet.uu.net
moraes@godzilla.ele.toronto.edu (Mark Moraes) (05/05/88)
In article <293@piring.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:
#In article <8805021554.AA06237@blandings.csri.toronto.edu>
##4) Xterm's understanding of geometry specifications for icons broke between
##X10 and X11. You used to be able to say:
## xterm -i =+180+290 '#-3+200' &
##to get an icon that was 3 pixels from the right edge of the screen. Now
##it puts the left edge of the icon 3 pixels from the right of the screen,
##which is not useful.
#
#I believe this might also be a twm bug. BTW, you are using old style
#geometry specifications; you should say '-geometry +180+290'.
#Unfortunately I believe the Toolkit has no -icongeometry option.
Nope -
xterm -iconic -geometry 80x24-1-1 -xrm 'xterm*iconGeometry: -1-1'
(which is the official way of specifying a geometry to toolkit
aplications, I take it!) doesn't work even under uwm. Looking at
the WM_HINTS through xprop (with uwm/no window manager), it sets the
x, y coordinates of the icon, and does it wrong.tlastran@esunix.UUCP (Tom LaStrange) (05/05/88)
> >4) Xterm's understanding of geometry specifications for icons broke between > >X10 and X11. You used to be able to say: > > > > xterm -i =+180+290 '#-3+200' & > > > >to get an icon that was 3 pixels from the right edge of the screen. Now > >it puts the left edge of the icon 3 pixels from the right of the screen, > >which is not useful. > > I believe this might also be a twm bug. I just tried this using uwm and the same thing happens. The problem is that by the time the window manager gets the icon position, it has been changed to positive pixel coordinates. I think the best I can do is ensure that the icon is completely on the display. Currently, with twm, you can specify coordinates which would place the icon off the display, and that is a bug. Anyone know if I can tell if the icon geometry coordinates were specified with negative offets? -- Tom L.