marcs@SLC.COM (Marc San Soucie) (11/16/90)
OSF Problem Report
=================================
Submitter Information (Include Email address at miminum)
---------------------
Submitter Name: Marc San Soucie
Organization: Servio Corporation - Beaverton, Oregon
Email Address: marcs@slc.com
Phone: 503-690-3526
OSF License Number: Could be 287
Hardware/Software Configuration
-------------------------------
Offering and Version: Motif 1.1.0
Component (Module): XmText
Client Hardware: Sun SPARCStation 1, 16Meg memory
Client Software: SunOS 4.0.3, X11R4 (MIT)
Server Hardware: SAME
Server Software: SAME
Compiler: ?
Problem Description
-------------------
Severity Level: Severe
Represents a problem which resulted in software functionality limitation
but had alternative work-around.
Date of First Occurrence: 11/15/90
One Line Description:
'next-page' and 'previous-page' do not move the insertion cursor
Full Description:
Using the above actions (via their default bindings to osfPageDown and
osfPageUp) in a multi-line text widget with gobs of text, the text in the
viewport moves, but the cursor does not. A subsequent cursor motion causes
the widget to jump back to the original position of the insertion cursor.
Repeat By:
As above
Proposed Solution:
The insertion cursor should be moved in 'next-page' or 'previous-page'.
Check out other actions, too. Let's make sure they all do the right thing.shap@sequent.com (Shap Shapiro) (11/16/90)
> One Line Description: > > 'next-page' and 'previous-page' do not move the insertion cursor > > Full Description: > > Using the above actions (via their default bindings to osfPageDown and > osfPageUp) in a multi-line text widget with gobs of text, the text in the > viewport moves, but the cursor does not. A subsequent cursor motion causes > the widget to jump back to the original position of the insertion cursor. Gee, I do not know that I would classify this as a bug. I seem to remember that this is the standard behavior on the word processing applications I have used on the Mac, and I wouldn't be surprised if the same help for PM on PC's. Just because a user is scrolling, is it really the correct thing to do to move the insertion cursor to some arbitrary spot? I do not have really strong feelings about this, but once I got used to it on the Mac, it seemed like the correct behavior. Shap ------------------------------------------------------------------------- Shap Shapiro | Sequent Computer Systems | | 15450 SW Koll Parkway, MS: RHE2-752 | {uunet|tektronix}!sequent!shap | Beaverton, OR 97006 | shap@sequent.com | (503) 578-4158 or 626-5700 | | fax (503) 578-7569 | -------------------------------------------------------------------------
marcs@SLC.COM (Marc San Soucie) (11/17/90)
I wrote: > One Line Description: > > 'next-page' and 'previous-page' do not move the insertion cursor > > Full Description: > > Using the above actions (via their default bindings to osfPageDown and > osfPageUp) in a multi-line text widget with gobs of text, the text in the > viewport moves, but the cursor does not. A subsequent cursor motion causes > the widget to jump back to the original position of the insertion cursor. Shap Shapiro wrote: > Gee, I do not know that I would classify this as a bug. I seem to remember > that this is the standard behavior on the word processing applications I have > used on the Mac, and I wouldn't be surprised if the same help for PM on PC's. > Just because a user is scrolling, is it really the correct thing to do to move > the insertion cursor to some arbitrary spot? I do not have really strong > feelings about this, but once I got used to it on the Mac, it seemed like the > correct behavior. I can't understand how one could get used to this. If I hit next-page a bunch of times, and I'm looking at text in the middle of the buffer, how am I supposed to start editing that text? Am I supposed to reach over, grab the mouse and click on the spot I want to modify? Phooey! Whether it's Mac-standard or not, it's unfriendly behaviour. No WP package *I*'ve ever used does this, and no incarnation of vi or emacs does either. Text widgets are *supposed* to be keyboard-driven. By definition. By nature. By Divine Law. If I have to be grabbing at mice just to move around through the text, we're all in trouble. Marc San Soucie Portland, Oregon marcs@slc.com
Eric.Rosenquist@CRC2.SKL.DND.CA (11/17/90)
> I can't understand how one could get used to this. If I hit next-page a bunch > of times, and I'm looking at text in the middle of the buffer, how am I > supposed to start editing that text? Am I supposed to reach over, grab the > mouse and click on the spot I want to modify? Phooey! Whether it's Mac-standard > or not, it's unfriendly behaviour. No WP package *I*'ve ever used does this, > and no incarnation of vi or emacs does either. Text widgets are *supposed* to > be keyboard-driven. By definition. By nature. By Divine Law. If I have to be > grabbing at mice just to move around through the text, we're all in trouble. Of the Mac programs I've used, none of them have had a keyboard action that had the same effect as clicking in the scroll bar. All of them however leave the insertion point alone if the window is scrolled using the scroll bar. I like this behavior since in, say, MS-Word, I can quickly zip around and view another part of the file and then return to the insertion point simply by typing something. Personally, I'd want PageUp and PageDown to move the window *and* insertion point by one 'page', unless of course every other Motif program on earth had them just moving the scroll bar around :-) Eric -- Eric.Rosenquist@crc.skl.dnd.ca Software Kinetics Limited 65 Iber Road, Stittsville, Ontario Canada - K2S 1E7 Phone (613) 831-0888
nazgul@alphalpha.com (Kee Hinckley) (11/17/90)
> I can't understand how one could get used to this. If I hit next-page a bunch > of times, and I'm looking at text in the middle of the buffer, how am I > supposed to start editing that text? Am I supposed to reach over, grab the > mouse and click on the spot I want to modify? Phooey! Whether it's Mac-standard > or not, it's unfriendly behaviour. I have mixed feelings about this. How about if it moves the caret but not the insertion point. Then you could use a translation (is there one?) to move the insertion point to the caret. I must confess that after 5 years of using Jim's editor that did it "wrong" I kind of liked it. It is definitely disconcerting to start typing and suddently find yourself transported far, far way (or does it do worse, and let you type but not show you where it's going?) -kee
nazgul@alphalpha.com (Kee Hinckley) (11/17/90)
> Of the Mac programs I've used, none of them have had a keyboard action > that had the same effect as clicking in the scroll bar. All of them More likely you simply don't have an extended keyboard with pageup and pagedown on it. Word and FullWrite both allow scrolling from the keyboard (actually FullWrite allows just about everything from the keyboard. 1.1 is available for pennies. It's buggy, but I highly recommend it as an example of how keyboard traversal ought to be done (and how marketing and development ought not to be done :-)).
dbrooks@penge.osf.org (David Brooks) (11/18/90)
In article <9011161714.AA06984@servio.SLC.COM> marcs@SLC.COM (Marc San Soucie) writes: > >I can't understand how one could get used to this. If I hit next-page a bunch >of times, and I'm looking at text in the middle of the buffer, how am I >supposed to start editing that text? Am I supposed to reach over, grab the >mouse and click on the spot I want to modify? Phooey! How else do you tell the machine precisely where your eyes are focused? Even if you have the right page on your 80x24 screen, the chances are 1 in 1920 (well, you know what I mean) that the cursor is at the right place without your moving it there explicitly. -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks "No, I didn't say I wanted a Bud light!!!" -- Oedipus
Eric.Rosenquist@CRC2.SKL.DND.CA (11/23/90)
> > Of the Mac programs I've used, none of them have had a keyboard action > > that had the same effect as clicking in the scroll bar. All of them > More likely you simply don't have an extended keyboard with pageup > and pagedown on it. Word and FullWrite both allow scrolling from the > keyboard (actually FullWrite allows just about everything from the > keyboard. 1.1 is available for pennies. It's buggy, but I highly > recommend it as an example of how keyboard traversal ought to > be done (and how marketing and development ought not to be done :-)). I just got a friend to test this for me because I don't have access to an extended keyboard any more. I used to use MS-Word 4 a heck of a lot *with* an extended keyboard, and I don't remember it working the way you describe (and according to my friend's test, my recollection of how it works is correct). In the Mac version of Word, the PageUp and PageDown keys move the insertion point and the window by one screen-full of data. Clicking in the scroll bar moves the window ahead/back but the insertion point stays put. I've never used FullWrite so I can't vouch for what it does. Eric -- Eric.Rosenquist@crc.skl.dnd.ca Software Kinetics Limited 65 Iber Road, Stittsville, Ontario Canada - K2S 1E7 Phone (613) 831-0888