Date: Fri, 10 Jan 1997 23:54:31 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Bakul Shah <bakul@plexuscom.com> Cc: Terry Lambert <terry@lambert.org>, gilham@csl.sri.com (Fred Gilham), freebsd-hackers@freebsd.org Subject: Re: A cool xterm? Message-ID: <199701110454.XAA01378@whizzo.transsys.com> In-Reply-To: Your message of "Fri, 10 Jan 1997 17:11:57 EST." <199701102211.RAA13433@chai.plexuscom.com> References: <199701102211.RAA13433@chai.plexuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> In the scrollbar used in `ups' (the debugger), the distance you drag > the cursor determines the *velocity* of scrolling: move the cursor > *anywhere* in the scrollbar window; press the left button and drag > the cursor up or down. The farther you drag it, the faster the > window scrolls. When you get close to the target, you can drag back > towards the original position and scrolling can be slowed down to a > crawl. If you overshoot, move past the original position to scroll > in the opposite direction. This is much like a single dial for fast > forward/reverse button on some VCRs. Very handy. But.. The way the NeXTSTEP scrollbars work, this isn't necessary. The size of the "knob" in the scroll bar is proportional to the total size of scrollable region. If you want to be in a particular part of the file, you simply grab the knob and drag it to where you want it to be. You can move up/down a line by pressing the buttons, or up/down a page by clicking the select (left) button in the scroll bar above or below the button. There are other modifications which can be done by holding the ALT key down, but few applications use them. Personally, I find the mouse button usage incredibly hard to use with the Athena widgets compared to the much simpler implementation that the NeXTSTEP ScrollView gives you. Heck, for the years I used NeXTSTEP every day, I never missed not having to screw around with an .Xdefaults file. I don't need that many ways to configure a UI with bad taste :-) Seriously, one of the thinks I loved about the Stuart terminal emulator on NeXTSTEP is that the scrollback buffer was essentially infinite (or could be if you wanted). It "did the right thing" when the screen was cleared and other cursor positioning stuff happened. Funny, I can't exactly explain what "the right thing" is now, all I know is that xterm and rxvt don't manage to do it, sigh. We could learn a lot from the UI design those guys came up with. My two-bit deep monochrome display on my NeXT pizza box machine still manages to look better than the technocolor, 24 bit deep X11 display.. Sorry for the digression into window system UI design.. louie > A similar scheme for selecting text would be nice. > > > I think the riginal complaint was that cleared screens did not get added > > as complete units to the scrollback buffer of xterm. > > Yeah, this would be better but can be somewhat confusing. Perhaps > a thin horizontal line should separate screens cleared this way. > > Also, there should be a way to dump lines to a file (on command) as > well as increase/decrease line buffer size.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701110454.XAA01378>