Conference bulova::decw_jan-89_to_nov-90

    I vote for changing pointer pattern and color.

    I vote for sending a message to OPDRV indicating the entry to and
    the exit from the mode - as well as indicating that CTRL-F3 will
    exit the mode.
    
    You *can* send a message to OPDRV.  The message will be put into
    the operator window.  AND if you have Opdrv messages trapped into
    the seesion manager window... ta-da.
    
    Or there must be some mailbox associated with the session manager
    messages.  You shouldn't have any problem opening a channel and
    writing to a mailbox from the driver.
    
    _Fred

    
    re. 2
    
    Sending a message to operator window works ONLY IF the graphics
    display is the console (opcom message will go to a VT220 if
    it is the alternate console) AND IF opcom broadcast is enabled.
    
    I am booted into DECWIN and I don't get any opcom messages at all
    which I kind of prefer!
                            
    
    
    Eva. 

    
    Is there a session manager mailbox for the messages that it prints?
    Then why not open the mailbox and write a message to it?  This should
    be possible from the driver without any problem.
    
    There is no meaningful change that can be made to the cursor that would
    help someone who didn't already know what the problem "could" be.  AND
    how does the cursor change work in relation to the USER cursor?  Does
    it inhibit all other cursor changes?
    
    Also, the idea that the driver cannot communicate back to the DECwindows
    server isn't really true.  The connection to the driver in the first
    place is a O/S specific interface in the server.  There is no reason
    that a new I/O function cannot be written that fires an AST to the
    server.  The server (being just a normal process, and having a device
    and O/S specific portion) can then do just about anything from sending
    a message, generating a pseudo-event to the window manager, or creating
    a window on it's own.
    
    There are a number of VMS-specific things like ^F2 and ^F3 which are,
    I think, important to have, but which cause confusion.  I'm sure that
    as time goes on this will get even worse.  So why not bite the bullet
    and architect a solution and not just hack a point solution.
    
    

    
    re. 4
    
    Of course there are ways to get to the server. We can generate an
    event, AST, etc. Yes, we can hack the server to put up something
    is a little box, but then you can't see what is underneath it,
    ie. you can't move it around without the window manager. Pause session
    will write over it. If you use a dialogue box, once you got rid of it, 
    you won't know what mode your are in. 
    
    As someone already mentioned before, pseudo mouse feature is not
    a commonly used. Educating the user about the fact that they can 
    customize the keystrokes to active pmouse (change it to something
    like CTRL-SHIFT-F20) will help with some confusion. Right now,
    pressing a mouse button cancels the pmouse function, so this
    should also help to alleviate the problem.
    
    I don't see any problem with changing the cursor pattern in
    relations to the "USER cursor". DECWPaint had it's own cursors.
    Or, we can make the cursor blink. Or we can reverse the foreground
    and background colors of the cursor. Or we can make the keyboard
    beep a tune.
    
    
     Eva.
    
     

    
    Huh?  If it's sent to the session manager and displayed in it's
    message area then the user will see the message (if it's up) or
    he won't (if it's an icon).  But in any case, there is a relatively
    standard place for it to be displayed and a common place for a user
    to look for "system" or "decwindows" messages.
    
    I dispute the fact that the feature is not commonly used.  This is
    all conjecture by DEC software engineers.  We don't even know how many
    VAX workstation customers use DECwindows, let alone the ^F3/F2
    features.
    
    I don't like the mouse button cancelling the mode (but that's just
    me).  But I do think that it's a good idea that there is a plain
    text display someplace that the user can look at and see:
    
    "Entering pseudo-mouse mode, press CTRL-F3 to restore the editing keypad"
    
    The poor shmuck who's just caused this to happen *is* likely to
    look at his session manager window.  More likely than he'll figure
    out what a flashing cursor is.  How and where that message gets
    displayed is another story.
    
    

    I disagree that the user is likely to look at the session manager
    window to see why the cursor no longer responds to the mouse (or that
    the arrow keys no longer affect the terminal cursor).  For one thing,
    if s.m.'s window is closed, the user can't open it because the mouse
    isn't working! (in his point of view).  Secondly, in the sites that I'm
    familiar with, users are trained not to fool with session manager, so
    they ignore it (and usually leave it iconized.)
    
    Admittedly, there are going to be people who will get themselves in trouble
    no matter what we do.  I think, however, that some kind of on-screen visual
    indication that the mouse control has changed will go a long way to
    alleviate the confusion.

How about a window that comes up at the cursor and disappears on the 
next ^f3 or mouse motion from the keyboard or mouse?

    Speaking for myself, I'd like to see the cursor change to four arrows
    laid out like they are on the keyboard.  Perhaps this should be
    combined with some other message so that it's not so subtle.  An option
    to hide the message either temporarily or permanently would be nice.

    re: .7 - as far as I know ^F3 doesn't disable the mouse.
    
    re: .8 - this is difficult to do, and potentially interferes with
             the use of the feature by putting a window on the screen.
    
    Let's look at the 2 things that need to be addressed.  First,
    the driving force is the loss of the WAIT light for those users who
    not only know what the feature is, but know what the WAIT light means.
    This is the problem that Ava was trying to solve.  This problem can
    even be generalized to ask how can we replace any or all of the LED
    indicators on a KB.  With the LK401 we lose 2, but one day I bet we
    lose all of them.
    
    Next, there is the problem of the guy who hit CTRL-F3 by accident and
    doesn't have a clue what the WAIT light means or any other
    non-intuitive indication (like a blinking cursor).
    
    Ava's cursor approach may be reasonable for the user who knows what
    he's doing, and just wants visual feedback.  At least it's something,
    that *can* be done in the driver and I can't think of anything that
    will make everyone happy.
    
    What I'm interested in is the second problem.  That is, the naive
    user who's accidentally gotten into what he thinks can only be fixed
    by rebooting.  Something that has been suggested is to generate a X
    event that indicates that a "LED" state has changed, this would
    coorespond to the points where the driver turns on or off any of the
    standard 4 LEDs.  The session manager can process this event and do
    anything from putting a message into it's display to popping up a
    dialogue box.  In addition, if the event is broadcast to all windows
    then individual applications (and toolkits) can be notified of LED
    state change and could do things like maintain a visual indication of
    the LEDs in the window.
    
    As an aside, I would *really* like a standard way to write to the
    session manager message area.  Here is a nice, neat, standard place
    to put system, application and window messages... but I can't figure
    out how to write to it short of a broadcast to TWA1:
    

re -1:

I, too am interested in the problem of the naive user, but I don't 
think it should be confused with LED issues.  The LED has only had 
meaning for the knowledgable user, anyway.

Also, while some standard method of "broadcasting" to a user would be 
useful I don't think we should wait to rationalize ^f3 until all of 
Xlib agrees on and extension.

I still think the only solution for the neophyte is a (customizable)
explicit window with some text that replaces the cursor momentarily to 
tell them what they have done and how to get out of it.

Since applications can run without the session manager I don't think 
it should depend on the SM.  I think that leaves the driver or server.

Bruce

Yes, but servers don't create windows.  But more importantly, servers don't
know what language the user speaks (though they do know something about the
keyboard the user is using).

Burns