Conference bulova::decw_jan-89_to_nov-90

    This is an indication that you're in mouse-less mode.
    If you type Ctrl-F3 , this mode toggles on and off. 
    The Wait light is supposed to be the indicator of when you're in
    mouseless mode.
    
    Paul

Sigh....

I know this has been answered in this conference quite a number of times,

CONTROL-F3 will toggel the pseudo mouse mode. When you see the wait light
on, then hit control-F3 to put it back to normal.

Why does it come on? Some folks accidently hit it when toggling the 
operator window. (CONTROL-F2)


I have marked this note with a KEYWORD so that it can be looked up in
future reference. The keyword in PSEUDO-MOUSE.

Jeff
(Beating the dead horse again)

re: -1

ooops, notes collision. But it needed the keyword, anyway

    I can't be 100% sure that I have never hit Ctrl-F3 by mistake, but I
    was caught in this situation once.  Might have been T5.3-1 or V5.3,
    but I don't remember exactly.  You sure this is the only way to get
    into this bind?

    --Simon

  I did a DIR/TITLE=ARROW and just under FIVE minutes I received a response. 
I'm here in Colorado Springs, CO and five minutes really isn't that long.

  Here is what I got...

--------------------------------------------------------------------------------
                                   DECWINDOWS
Created: 30-OCT-1989 11:10         2171 topics        Updated: 30-JAN-1990 20:02
            -< See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit >-
 Topic  Author               Date         Repl  Title
--------------------------------------------------------------------------------
   245     PSG::BUCHANAN     17-FEB-1989     4  Arrows conrol pointer...Why?
   380   GLDOA::HACK         10-MAR-1989     5  Loss of arrow keys & locked
 'wait' light.
  1038  PAXTON::MOORE        29-JUN-1989     3  Where did my arrows go?

  1767   TOWNS::SEPPI        20-NOV-1989     1  Lost arrow keys with DECW v2 
upgrade.
  1771   ELRIC::MARSHALL     20-NOV-1989     0  narrow file menus in VMS5.2
  1879     RDF::RDF          10-DEC-1989     2  arrow keys now move mouse..
  2056  BRSIS6::BUTTIENS     17-JAN-1990    12  Arrow keys make my pointer
 move, not the cursor ...

    
    Anyone ever consider the fact that the "wait" light isn't exactly
    intuitive?  Where does the user look?  In the index under "Wait
    Light"?
    
    Since we're forced to live with this icon box, why not re-implement
    this feature so that a new icon is created that says "In Mouse
    Emulation Mode.  Use CTRL-F3 to resume normal edit key mode".
    
    

Since the driver is the one who intercepts the control-F3, it would have
to build a message to some client application (Window manager? Session
manager?) to have this accomplished. Actually after talking with Bill
Matthews, I like the idea of having to press CONTROL|SHIFT"|F3. THis will
make it harder to accidently go into brain-dead mouse mode.

    RE: .6, .7
    
    Either of these solutions sound good.  It should be much harder to get
    into the "dead mouse" mode than it is, or there needs to be a fully
    explanatory message when the mode changes.  The current solution of 
    lighting the "wait" light is thoroughly inadequate.  It tells the user
    absolutely nothing.  As a user who has experienced this problem and
    has seen others run into it, I can state that the current scheme is
    inadequate.  Fortunately, since I follow this conference regularly I
    was able to find the solution.
    
    RE: .5 and prior
    
    A "PSEUDO-MOUSE" keyword may help the developers find the other topics
    in the conference on this problem to point out to users who have run
    into the problem, but it won't help users find the notes.  The keyword 
    doesn't describe the symptoms, it gives the name of the disease - not 
    too helpful if you want to find out what disease you've got.  The
    frequency with which the problem is reported should be a pretty good
    indicator that the problem is worth fixing.
    
    - Dave

Thanks for the help.  My problem is that I never played with the cursor keys for
long enough to notice the pointer move.

I vote for the <CTRL>Shift-F3 solution.  It should be much harder to get into
this predicament than it is.

	I do not support the make it harder solution. Life is hard enough 
	without introduced difficulty. The user should be informed that his 
	mouse is dead.  Why should the arrow keys be used. ?? I have a 
	customer who believes that his people on the shop floor are not 
	able to handle a mouse. He believes also that the rat will get dust in 
	its entrails and and wishes to have a backup system. He demanded that 
	the pointer should be moveable by other means. I then plotted the
	demise of the mouse and as a by product I saved myself having to reboot
	the system whenever that WAIT light went on. 

		Rgds,

    AAAAAAAAAAAAAAARRRRRRRRRRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHH!!!!!!!!!!
    
    (There, now I feel *much* better :-)
    
    I'm very tempted to say "give me a break!"  We really are not talking
    about that great a level of difficulty in pressing the Control key and
    the Shift key simultaneously.  Admittedly, I am a touch typist (I
    learned way back when on one of those old Royal manual typewriters that
    were guaranteed to cause a hernia if you tried to lift it [now THAT
    machine was a masterpiece of engineering, IMNSHO] :-)  However, I just
    really have a hard time believing that we will be driving anyone to the
    brink of suicide owing to the added difficulty of depressing three keys
    instead of two. :-) :-) :-)
    
    Really, how often is this meta-feature used?  How often is it
    accidentally tripped over?  Count the number of notes that appear in
    this very conference from people who I would wager are competent to
    handle a mouse :-)
    
    Of course, if I had my way, I would get rid of Control-F2 as well as
    Control-F3...
    
    					- Ken

          
>    Really, how often is this meta-feature used?  How often is it
>    accidentally tripped over?  Count the number of notes that appear in
>    this very conference from people who I would wager are competent to
>    handle a mouse :-)
>    
>    Of course, if I had my way, I would get rid of Control-F2 as well as
>    Control-F3...

    It's easier to determine that there is a problem - because it generates
    noise - than it is to count the number of customers using it.  And some
    individual customers count more than others :-)
    
    

how about if the cursor mask inverts every so often while you are in this mode

This will give you some visual indication that you can hardly miss if you are
in this mode, we should make sure that it doesn't invert too fast or it will
be hard to position.

Mike

Re: .13

>how about if the cursor mask inverts every so often while you are in this mode
>
>This will give you some visual indication that you can hardly miss if you are
>in this mode, we should make sure that it doesn't invert too fast or it will
>be hard to position.

So instead of people saying "my arrow keys don't work and the Wait light
is on" they'll say "my arrow keys don't work, the Wait light is on, and
every few seconds my cursor gets inverted".

I think it would be preferable to display a message like "Entering pseudo
mouse mode. Press CTRL-F3 to return to normal mouse mode."  Since CTRL-F3
is implemented in the server, though, it may not be easy to display such
a message.  We should at least make it harder to activate the mode accidently;
CTRL-F3 is too close to CTRL-F2.

				-- Bob

If it's hard to display the mode message from the server, could you display it
in the operator window instead of the normal display?  I guess if this were
done the arrow-mode switch would certainly have to be moved away from the
operator window key...

Nick

>Note 2170.11       An Oldy-But-Goody--The "Wait" Light Problem          11 of 14

>                      -< How difficult is it REALLY? :-) >-
>
>    AAAAAAAAAAAAAAARRRRRRRRRRRRRGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHH!!!!!!!!!!
>    
>    (There, now I feel *much* better :-)
>    

	Hi Ken,
>
	Noting often does not give one the necessary time or space to write
	a problem thouroughly. I apologise.


	My point is that the developers of this wonderful SW... (sincere 
	complement) are so deep into it that they are unable to see a 
	problem.  
	The sooner that someone admits that to drastically change someones
	environment and only to shine a little green light that does not 
	clearly indicate the state is a bug, then quicker this discussion 
	will end.
	There are 3 solutions to this problem.
		1. The wait light shoud be labelled "no Mouse", "Keypad 
		   Cursur control"... etc
		2. The SW should be changed to produce an icon or some 
		   visible on screen message indicating the change of 
		   state.

	And incidentally in VMS 5.3 the problem is also fixed in that when 
	you hit Ctrl F3. the 'rat (mouse) does not lose control. The keypad
	shares control with it. It is not fixed in that the green light 
	tells 	you to wait. (for what)

	The successful SW is SW that which is intuitive. The sooner that 
	>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^~~~~~~~~~<
	developers of SW realise that the normal user of SW does not have 
	time to be a professional engineer and read reams of computer 
	documentation the more of the stuff that we will move. (SELL)

		Rgds,

Re: .16

>	There are 3 solutions to this problem.
>		1. The wait light shoud be labelled "no Mouse", "Keypad 
>		   Cursur control"... etc

This isn't a long term solution because future keyboards won't have a
wait light.  It also won't help people who already have workstations with
LK201s, unless we go to the expense of shipping them special label strips.
Even in the "medium term" of new systems shipped with the LK201, it would
cost real money to have to put different labels on workstation LK201s than
on terminal LK201s, although this cost may not be significant.  Fundamentally
I agree with you that a light that means "your arrow keys now move the
mouse" should not be labelled "Wait".

>		2. The SW should be changed to produce an icon or some 
>		   visible on screen message indicating the change of 
>		   state.

Yes.  This is the justifaction for there being no Wait light in the LK201
replacememnt: software or firmware is supposed to put up a visual indication
on the screen.  The main problem seems to be that for technical reasons it's
hard for the server to put up this message.  I'm not sure that an icon would
be intuitive enough, but at least it would encourage the user to look in the
manual to find out what the icon meant.

				-- Bob

>>	There are 3 solutions to this problem.

(: I think we have heard a lot more than 3 possibilities. :)

Here's another:  Get rid of the feature altogether.

Ironically, one of the big deals about the MOTIF toolkit is that it is fully
functional without a mouse.  The arrow keys are interpreted by
client-side software to "emulate" the mouse in a *usable* way.  For example,
the arrow keys move focus from one pushbutton to another in a single
keystroke rather than pixel-by-pixel.

Given that using a paint program, etc, is still practically impossible to use
without a *real* mouse, the pseudo-mouse never was a real solution.
Applications that are toolkit-based and don't involve intensive
graphical input will all eventually work in a mouse-less mode.

Just rip the code out and forget that it ever existed.
I'll bet you can't show me two customers who really depend on it, anyway.
And MOTIF will make the mouse even less "critical".

JMHO

-steve-

    
    You know I bet a good number of us pontificating about this haven't a
    clue what customers use these machines for.  You'd think to listen to
    us that all they do is menu's and motif is going to fix that.  Quite
    a few engineers I know can't even *name* two of thier customers let
    alone find two that use a feature.  They'll find *you* when you remove
    something they need: 1-800-DIGITAL
    
    _Fred

This all reminds me of the argument surrounding removing another software
perversion:  the fact that VMS's SET UIC command also changed your default
directory.  After much wailing and gnashing of teeth and worrying about
customers who may be depending on this misfeature, it finally was removed.
Guess what?  No great hue and cry.  In fact, as far as I know, there was not
one complaint.

If we really want to be overcautious about the whole thing, then leave the
code in place, but ship with the feature disabled by default.  Use some sort of
server startup option or SYSGEN parameter or something like that so that if
anybody really does want the thing, they can turn it on.  The important thing
is that there be no way to get into this mode by default.

--PSW

>
>(: I think we have heard a lot more than 3 possibilities. :)
>
>Here's another:  Get rid of the feature altogether.
>

Hello Mr. Moderator, 
	Can we confirm that this is not serious "discussion" to remove the 
	feature. 

>
>Just rip the code out and forget that it ever existed.
>I'll bet you can't show me two customers who really depend on it, anyway.
>And MOTIF will make the mouse even less "critical".
>
	I can show you one. He does not like mice and one question was "can 
	I make the aplication work without a mouse?". My answer was yes you 
	can without any extra programming or tweaking. The mouse is there 
	to enhance performance. Should it go wrong there is an quick 
	fallback. In a short while the mouse will be an accepted piece 
	of HW. There are still people out there who do not believe in them.
>
>-steve-
>

RE: .21

Does the revenue we get from your one customer compensate for the expense of
processing SPRs and service calls from the countless other customers who trip
over this feature?  I doubt it.  Especially since by your own admission we're
only talking about "a short while" before mice are universally accepted.

--PSW

>Does the revenue we get from your one customer compensate for the expense of
>processing SPRs and service calls from the countless other customers who trip
>over this feature?  I doubt it.  Especially since by your own admission we're
>only talking about "a short while" before mice are universally accepted.

	Brief answer.....     YES
>--PSW
The following is for the eyes of Mr PSW.
>

To explain a little.. When we make a mistake the easiest way out is to
admit it and correct as quickly as possible. This wait light "feature" is a 
mistake. There is no other word for it. We said 'wait' when we meant to say 
was 'your mouse is dead' etc... The wait light is sitting there in between 
'meaningful' text like like 'hold screen, insert/overstrike etc... 

As soon as you try to justify an error, especially on the grounds that the
man who pays your salary is too stupid to understand what you meant. The
ground beneath your feet begins to fall away. AND the magnitude of the
error grows. 

Expressions like "go away and read the manual" no longer sells computer 
software. There are plenty of people out there who are willing to stab at 
SW which does not require manual reading. And secondly they will then
listen to the user after the SW author has failed to make himself clear. 

If one looks from the terminal occasionally there is a world out there of 
people who expect us to talk their language.

	Rgds.

RE: .23

You didn't understand a single word of my previous reply, did you?  I'll
try to state it more plainly.


The CTRL-F3 mode that allows the arrow keys to be used to move the pointer is a
mistake.  It should be removed from the code.  Lighting up the "wait" light to
indicate that this feature is in effect similarly should be removed.

So there is one potential customer out there who actually wants to use the
arrow keys in place of the mouse.  Too bad for him.  When you factor in the
expense of answering SPRs and service calls from other customers who
accidentally activate the arrow-key-as-mouse feature, we make more money by
removing the feature (and the expense of all those service calls) and losing
that one customer's sale than if we keep the sale and incur the service expense
and ill-will of those other customers.

--PSW

This reminds me of the discussions about XON/XOF aka ^S/^Q and ESC, which
is also in the context of keyboards and strong resistance to accepting evolution
by very small minorities.  While the current keyboard pointer feature currently
causes consternation and much discussion at all too frequent intervals, removing
this feature would simply change the discussion to `why don't we support this
feature'.

The real problem is that we don't have a keyboard with integral pointer
capability, either in the form of a track ball or a matrix of arrows and buttons.
So, there are some who are willing to settle for the simulation of the latter
with the editing keypad.

The requirement is to make the current keyboard pointer capability more of a
explicitly selectable feature, while retaining is capability.

Based on comments from Jim Gettys in the context of bitpad support, I suggest
that the solution is to provide the current kind of support as a server
extension, add the necessary Xlib support to use it, and add the customization
options to the session manager to allow this to be customized by each user.

This should be done in conjunction making the operator window a user option as
well.  I'm sure that there are a number of confused users who can't understand
why every once in a while, there display gets screwed up and the mouse no longer
seems to track correctly.

And in fact, I suspect that the reason that people run in the keyboard mouse
feature is that something comes up in the operator window and someone tells them
that the way you get it back to normal is to "push control or shift plus one
of the function keys - keep trying until it returns to normal".

Entered in QAR V2.4, database DECWINDOWS-IFT as 3972

    Completely eliminating the feature strikes me as throwing out the baby
    with the bathwater. I haven't done this recently, so maybe the need is
    gone, but I recall in UIS days switching to keyboard mouse in a
    graphics program to ensure that the line I was drawing didn't waver
    from vertical. The arrow keys allow this with absolute certainty; my
    hands on a mouse aren't good enough. (Graphics programs which only
    provide one line drawing mode are the problem.)

    The problem isn't the feature; it's the ease with which the feature can
    be accidentally invoked, and the obscurity with which the mode is
    displayed. Making it harder to invoke - via Ctrl-Shift-F3 - strikes me
    as an adequate solution, and far better than throwing it out entirely. 

>
Re .24,

	I again aplolgise if you are the person who designed this feature.
	Perhaps I have been a little direct with the criticism. It then
	appears that I am treading a little heavily. 
		When you have cooled off I think that you will see that if we
	follow your logic of removing all coding that WE fail to document
	adequately we will end up with very thin systems. 
		On to your point of 'the feature that we removed that did 
	not bring any customer complaint'. You must remember that many 
	customer complaints are written in their checque books. NOT in the 
	notesfiles. DIGITALS success is related to the richness of its 
	offering and the concern for the customer.
		Rgds,

re .27:  No, Paul did not design that "feature".  We did in the server/hardware
group.  We did not have the feature initially, although it had been in UIS.
We got many many complaints (not to mention CSSE's requirements).  So we put it
in.  The only place that this can be done efficiently is in the driver, so that
is where it went.  Unfortunately, the driver is not in a position to put up
messages on the screen.  The only method available to the driver to give ANY
kind of feedback is keyclick or the lights.  (Maybe we should have the
keyboard go click-click-click when we are in kbmouse mode? :-)

So I would argue that the kb mouse does make SOME sense.  As Paul Beck said,
it is nice when you want to draw perfectly horizontal or vertical lines.  There
is the issue of a $50 dollar mouse making a $10K or more workstation unusable.
I think that former UISers like me initially liked being able to wheel the pointer
around without taking our hands off the kb.  As the pointer use increases, and
especially with pulldown menus, that latter reason has become much less
important.

In any case, though, I strongly agree with the people who have said that mysterious
"features" annoy customers, and the FTFM does not cut it in today's world.
I think that the current kbmouse design has two basic flaws:  (1) It is too
easy to get into. and (2) the feedback is insufficient.

We thought we had made it sufficiently hard, having to use both ctrl and F3, but now, it turns out that as modified function keys
are being used in more applications, it is more common to have your finger on
the control key.  I have already explained that feedback on the mode is real
hard to do.  One could, presumably, add extensions and stuff so that a client
somewhere could do a pop-up, but that seems excessively complicated and would
depend on a session manager that understood.  Maybe a console message would be possible (I'm
not a driver person...)

It seems to me that the best all-round compromise is to make it much harder to
get into kbmouse mode.  Maybe even CTRL/Shift/Alt F3?  Maybe hitting this
combination three times in a row within 1 second?  This would keep people
who did not know about it from getting into the mode.  If you did know about it,
you could get into it.  I would not object to an auto-cancel (with a mouse
movement) either.

Burns

>	re .28

	Hello Burns, my name is Stephen

	I feel as if I am talking to someone who is on my side. 
	Dont whatever you do change it to ^shift+lock+tab. This is the sort 
	of thing that Sinclair ofered and we know what happened to them!!
	This is also the kind of thing that happen when a book falls on the 
	keyboard. 8*) (and bounces).. 8*)

	Leave the switch "Ctrl F3" as it is... please dont fix it it is not 
	broken. We should make everything easier to get rather than 
	"harder".

	If mouse movement or clicking can switch it off then this is the 
	obvious and intuitive Solution. If the user is in the mode either 
	wilfully or accidentally then when he needs the mouse he has it. 

		Rgds,
			Stephen

    
    A message
    
    "%DECW-I-MEMODE, Entering mouse emulation mode, press Ctrl-F3 to exit"
    
    sent to OPCOM by the driver just might solve the general case...
    

>>>    Completely eliminating the feature strikes me as throwing out the baby
>>>    with the bathwater. 

    Totally!

>>>    To ensure that the line I was drawing didn't waver from vertical. 

    Oh, that's good. That's very, very good. Why didn't I think of that?
    
    Even better, you can also use keyboard-mode to move the pointer exactly
    one pixel, something that always frustrates me in RAGS.

    - - - - - -

    Yet Another Hair-brained idea:

    Could we sell one of those cheap keyboard function key label strips,
    the ones that say "Hold Screen" and "Print Screen" instead of "F1"
    and "F2", and have it say "Mouse Off" instead of "Wait". ???

    Kevin

RE: .27

Some customer complaints are not worth listening to.

Suppose, for example, that I insist I will not buy your workstation unless
there's a pile of fresh dung in the monitor cabinet, because I happen to like
the way that smells.  Should DEC therefore ship all their monitors with dung
in them, because one crazy potential customer out there wants it that way?
Even if it means for every one customer we attract this way, we'll drive another
1000 away?

What I'm saying is that if you weigh the benefits of this so-called feature
against the problems that it causes, I think the best thing to do with it is to
remove it from the product.

I am not advocating making our systems feature-poor.  I am advocating making
them MISfeature-poor.

--PSW

Actually, If I add all of the replies on this topic together, I'll bet 
it would be a record!

I would like to see a serious reply the shows why having real mouse activity
automatically cancel F3 mode does not solve this problem!  And this can
be done in the driver.  And if you mouse has gone screwy, do as I suggest
in the previous thread: unplug it and get a new one...

	re .33: I would like to see a serious reply the shows why having real
		mouse activity automatically cancel F3 mode does not solve 
		this problem! 

	Is there some kind of mouse-control board in the monitor that can go
	haywire and generate mouse apparitions, even after the mouse has been
	flung to someone else's cube?

	Regards, Robert

Is there any requirements for equal access by handicapped users that supports
the need for the mouseless mode?  I would think that users with limited fine 
motor control would benefit from keyboard control of the pointer.

Wook

    I don't think the current keyboard mouse would be useful to someone who
    was so handicapped they couldn't use a mouse.
    
    	Jon

       
       I heard a talk by John Whiteside about Useability Engineering. 
       In the talk, he discussed some studies that were done to
       measure the usability of certain systems (All-In-1 and UIS, as
       I recall)
       
       I understand that Mr. Whiteside is in charge of Useability
       Engineering for DECWindows.  What does his group have to say? 
       Have they been asked?
       
       Since there is concern about what Customers might want,
       should'nt a Marketing survey be performed?
       
       Without that information, how about providing the ability for
       users to choose.  Isn't that the fundamental mode of operation
       for DecWindows?  (How many readers of this conference secretly
       covet the "Let the User Decide" personal name?)  
       
       Provide flexibility and reasonable defaults.  There exist
       methods for determining what is reasonable.
       
       
       		OK?
       
       			Paul Komar
       			VAXCluster Design Validation.
       
       P.S.   Here are some more questions:
       - Is what is "intuitive for you the same as what is intuitive for me?
       - What about for U*ix users?
       - What about for secretaries? (perhaps the hardest audience to
       				      satisfy -- How many have time to
       				      take training?)
       
       	Disclaimer:  The above ideas only represent what I believe at
       this time...
       

People, people, PEOPLE.  Get a grip!  :-)

When you select "mouseless mode" (which should really be called
"arrow-mouse" mode) this does *NOT* shut off your mouse!!! Try it for
yourself.  The arrow keys will move the pointer, but the mouse will STILL
move the pointer.

Therefore, the argument in .34

>	Is there some kind of mouse-control board in the monitor that can go
>	haywire and generate mouse apparitions, even after the mouse has been
>	flung to someone else's cube?

doesn't make sense because CTRL-F3 mode doesn't shut off mouse input.  If
you had a bad "mouse-control board", you'd be getting bogus mouse input and
there is not way to shut it off!  Call field service and go home.

The solution suggested in .33 is right.

>I would like to see a serious reply the shows why having real mouse activity
>automatically cancel F3 mode does not solve this problem!  And this can
>be done in the driver.  And if you mouse has gone screwy, do as I suggest
>in the previous thread: unplug it and get a new one...

If:

1).  If you want (as in actually consciously selected) CTRL-F3 mode, it can
be invoked with no added effort (no SHIFT-CTRL-META-squiggle-F3 needed to
invoke it).  Unplug your mouse, flip it upside-down or just don't touch it
as long as you want to be in arrow-mouse mode.

2).  If you turned it on by accident, chances are you'll move your mouse or
give some sort of mouse input which would cancel F3 mode.  95% of all users
who accidentally entered CTRL-F3 mode would be back out of it probably even
before they noticed they were in it.

3).  If you had a bad mouse that generates noise, unplug it and do as #1.

4).  If you have a bad "mouse-control board" (if there is such a thing),
you're sunk anyways.  I've never seen this situation happen though.

Keep F3 mode easy to get into (ie.  CTRL-F3), make it easy to get out of
(real mouse movement to cancel F3 mode), and document the hell out of it.

-Mike

> 3).  If you had a bad mouse that generates noise, unplug it and do as #1.

I insist that the documentation instruct you to `Swing the mouse around
your head three times by it's tail, release the tail, and shout ``Hughhh''.'

P.S: I didnt invent the .33 solution, I was echoing some much wiser and
more serious person from one of the other arrow key threads!

P.P.S.: Why do you ask if I am a cat lover?

Can the server implement a 'blinking' mouse cursor ? This would atleast give
some feedback to the user that something has changed. Also, it makes it an
easy condition to describe on the phone or to look it up in the fine manual
under 'Blinking cursor'.

Just my 2 cents...

Jatin

Is a blinking cursor any better than a blinking wait light?

Burns

I almost never look at the lights on my keyboard.  I'm not sure why I never
got in the habit, but even after all these years I still bite myself now and
again with the hold screen.  ;-)

A blinking arrow is *much* more noticeable, I'd say.


Brian

	I thought that this was finished. 

	The mouse never loses control in 5.3. It should over ride and 
	switch off the Ctrl F3 any time it is touched. 

	the user should be informen in clear concise German on the opcom
	screen of what has happened.

		Rgd,

The blinking cursor idea is ***TERRIBLE***!!! F3 mode is supposed to be able
to be used as a substitute to the mouse, it's not some error contition! One
of the most useful reasons for using F3 mode is to very accurately position
the cursor.  Try doing THAT while its BlInKiNg.  Sure, it's more noticable,
but it also makes F3 mode unusable.  That's like shooting yourself in the
foot.

C'mon folks, a real solution has already been proposed.  If you're in F3
mode and you move the mouse, it cancels F3 mode.  If its feedback you're
looking for, a blinking wait light might be more noticable than a steady
wait light and it wouldn't hinder the use of F3 mode.  Not everyone runs
OPCOM and others disable the operator window so OPCOM messages aren't
enough.

-Mike

RE: .44

>If you're in F3
>mode and you move the mouse, it cancels F3 mode.

I'm not sure that will address the problem of people accidentally hitting
CTRL/F3 and then finding the arrow keys don't work.  Now they'll find that
the arrow keys don't work for a while, and then just as mysteriously as they
stopped working, they start working again (of course, what really happened is
the user moved the mouse at some point in time).  This could still be an SPR
generator.

--PSW

In any case it doesn't work that way in V5.3.  Moving the mouse always
moves the pointer, but ^F3 mode remains in effect if it was in effect.

Curiously enough, the Wait light is merely ON, not blinking...

	paul

I just saw that the VT1000 has implemented pseudo-mouse mode.  Unfortunately,
there is NO indication that this is on - the keyboard doesn't even have
a wait light!  Sigh...

			Steve

    Despite what I said in .4, I now see that I must have hit Ctrl-F3
    accidentally when going for Ctrl-F2, like Jeff said in .2.
    
    I have not found any real use for this feature yet, although I did try
    using it to position windows precisely on the edge of the screen.  This
    maneuver requires using the 'Find' key to hold MB1 down.  ('Select' is
    click on MB1.  'Insert Here' and 'Prev Screen' work similarly for MB2. 
    Is all this documented somewhere?)
    
    --Simon
    

    This brilliant feature is actually documented:
    
    DECwindows V1.0 User's Guide p. 2.2
    DECwindows V2.0 User's Guide 3.13
                                   
    Regards,
    Jesper

    Was that the UWS UG?  In the VMS DECwindows User's Guide (VMS V5.3)
    I found the documentation on pp. 3-26,3-27.
    
    --Simon
    

    Bookreader doesn't tell me the pagenumbers. 
    
    Mayhaps pp. 3-26,3-27 = paragraph 3.13?
    
    Jesper

re .50

You won't find anything about this in the UWS docs.  Fortunately UWS doesn't
have this feature.
				Jeff

If ctrl-f3 is a crock, then so is ctrl-f2, because it doens't do anything
useful either.  On my system it just puts cross hatches on the top 2/3s
of the screen and disables the mouse and there is not hint as to how to
fix it.  (Actually, its worse than that; something I did while seeing
what it does, caused DECW$SERVER to set its working set limit to the
minimum so all it did was pagefault until I restarted the server..)

I still think that they should be setup options because I have actually
put the keyboard mouse to good use and I assume that some people find
the weird screen mode useful for something, but I have no idea what it is.

Another vote to keep the feature, just change the way it is
activated.  Taking a clue from the way the Amiga reboots,
how about replacing Ctrl/F3 with Shift/Shift/F3  (holding both
shift keys down at the same time...)  They ARE treated as two
seperate keys right?

Of course it requires two appendages, or an amazing one-handed
grip...

Of course deactivation on mouse-movement..

RE:-1 So the upper row of keys corresponds to mouse button hold-down!  I
always wondered.

-Dave

On the LK201, both SHIFT keys are the same scan code.

RE .-2:  ``of course it requires two appendages''

I am surprised that, since you recognize that your suggestion requires
``two appendages'', you even made such a suggestion.  I have a
neighbor in the software business who has only one arm.  She manages
most control sequences and capital leters fine, and is a rapid typist.
But to boot her PC requires her to resort to the (in my opinion) degrading
expedient of using a pencil with her mouth (You know: CTRL-ALT-DEL).  I
get quite annoyed when I encounter SUGGESTIONS of gratuitous multhanded
sequences to do ANYTHING, and positively angry when someone actually
IMPLEMENTS one.  

In this case the CTRL-F3 sequence is one handed as it should be.  For
those who feel that it is too easy to hit when going for (say) CTRL-F2
do not suggest a multihand seqence, simply suggest moving the function
to CTRL-F4.  This will place a buffer space between the two keys
reducing miskeying to almost nil, and still preserve the one-handedness
of the operation. 

Re: .56

>In this case the CTRL-F3 sequence is one handed as it should be.  For
>those who feel that it is too easy to hit when going for (say) CTRL-F2
>do not suggest a multihand seqence, simply suggest moving the function
>to CTRL-F4.  This will place a buffer space between the two keys
>reducing miskeying to almost nil, and still preserve the one-handedness
>of the operation. 

This sounds like a good idea (although I still think there needs to be better
feedback that the workstation has entered a new mode), but I wonder if there
could be a potential conflict with the VT330/VT340's use of CTRL-F4 to control
split screen windowing.  It would be better if there were a standard key
sequence to go into arrow key mouse mode that would work regardless of whether
you were on a terminal or a workstation.  (Of course, currently the mouse is
not critical for operating the terminal, so there is no arrow key mouse mode
on the VT330/VT340.  I'm thinking of a future terminal that might use CTRL-F4
for split screening but would also have a need for an arrow key mouse mode).

				-- Bob