Conference bulova::decw_jan-89_to_nov-90

The best way to handle the special keyboard is to write 
a terminal class driver for it as we have for the lk301 and the
mouse. The DECWindows device driver manual documents how to do this
and you can look at our keyboard and mouse code too. The terminal
port driver handles all the uart hardware and our indriver and macros
handle the driver/server interface so all the class driver has to do
is decode bytes from the device via the terminal port driver and fill
in X event packets for transmission to the server.
					Bill

    This may or may not help: I was once able to get the Create Terminal
    and Create Fileview options to gray out by editing the session manager
    resource file. You will also need to gray out the Customize options
    since they allow users to say whether to start terminals automatically
    upon login..

    RE: .1

    Thanks for the ideas.  We'll check 'em out.  Fortunately, the custom
    keyboard isn't that much of an issue as we can talk to it through a
    serial line and $QIO.  Basically we should have to modify the code to
    generate X events instead of stuffing keyboard/mouse events into the
    VWS "type ahead" buffer.

    Using a class driver to do this would be a much more reasonable way to
    do things, in my estimation.  If things work out, we'll move in that
    direction. 

    RE: .2

    Thanks for reminder for using X resrouces to disable Session Manager
    options.  I hadn't thought of that as a first approach and I should
    have.  It would probably help in a prototype environment, but these
    folks really don't have a need for the Session Manager.

    RE: .0

    Any other inputs?  Does this mean that the Session Manager doesn't
    really do anything in the DECwindows scheme of things?


    Mike Endsley
    SWS @ STO

RE: .0...

I'd still like to see an answer to the questions asked in .0, namely:

    o	What programs/applications are involved in the initial username
	verification on the Login dialog box.  Is it only LOGINOUT?

    o	Once the username/password has been authenticated, how is the
	Session Manager and Window Manager started?  What command
	procedures, executable images, and logicals are consulted to locate
	the applications?  What order do the operations occur in?

    o	Assume for the moment that the Session Manager is removed from the
	DECwindows environment.  What Session Manager functions would we
        have to duplicate in the user's application code? 

    o	Is there any definitive documentation on writing X11 window
	managers?  I hope it doesn't get that far, but if it does I'd like
	some idea of the references/resources that might be available.

I am trying to start alternate window managers on a per-user basis, and
cant seem to get the session manager (or whoever) to do it for me...

    
    1. 	decw$startapps.com creates a WSA device which contains the current 
    display,server,screen,transport information.  It then defines
    decw$display logical name to point to that WSA device.  It then runs a
    program called decw$startlogin.exe and exits
    
    2. decw$startlogin.exe gets the definition of decw$display - WSAx.  It
    then sends a message to the job controller that there is unsolicited               
    input on that device.
    
    3. The job controller creates a process running loginout with
    sys$input=WSAx. (The job controller was not changed for DECwindows. 
    This is the same mechanism used when you hit CR on a terminal).
    
    4. Loginout does a getdvi on sys$input and determines if the device is
    a workstation device.  If it is, it image activates decw$loginout.exe. 
    At various places in loginout, the various routines in decw$loginout
    are called (prompting for username/password via dialog box, putting up
    the logo, taking the logo down, prompting on expired passwords). 
    Loginout does the username/password verification.
    
    5. Loginout then lines up some command procedures to be run in the
    current process when image rundown of loginout occurs and DCL takes
    over.  On a terminal login these are sylogin.com and login.com.  For
    DECwindows, they are decw$sylogin.com, decw$login.com,
    decw$startsm.com.
    
    6. Right before image rundown of loginout, decw$loginout.exe reads the
    various session manager and user resource files and stores the
    resources as a property on the root window.  It then translates
    the logical name decw$winmgrexe and does a CREPRC running that image.
    It sets sys$output on the CREPRC call to the current definition of
    decw$display.  That way the window manager will connect on the same
    display as the session manager.  
    
    7. Image rundown of loginout occurs and decw$sylogin.com and
    decw$login.com are executed.  Finally decw$startsm.com is executed.
    
    8. decw$startsm.com has a $run decw$session.exe command  in it which
    starts the session manager.
    
    9. The session manager then looks at the values of two resources in the
    session manager resource files to determine how many decterms to
    execute and whether or not to start FileView.
    
    10. The session manager then creates a pseudo terminal device and puts
    the device in the PCB as the terminal name for this user.   This allows
    all broadcast messages to the current user to be displayed in the message
    area.
    
    11.  The session manager then looks at the customization settings of
    the user and  makes the appropriate XLIB calls to set pointer shape,
    mouse button arrangement, keyboard setup, etc...
    
    12. Then the session manager sits there waiting for the user to either
    	Pause, Quit, Customize, Print Screen, or Create and application.
    

    RE: .5

    Excellent.  That helps muchly.  Next in the sequence of interest:

    How does loginout get restarted (and how does it find its WS device)
    when one quits from the session manager?

  > How does loginout get restarted (and how does it find its WS device)
  > when one quits from the session manager?

	The session manager does the exact same thing as decw$start_login.exe
	before exiting, i.e. it sends a mailbox message to JOBCTL.

I assume that it is also the session manager that changes the cursor from
the watch to the normal pointer right?  What software sets it to the
watch cursor in the first place?  If you don't use the session manager
how is the right way to change it?

    
    No, when the server resets, the cursor changes back to the normal
    pointer for the login screen.
    
    When you login, decw$loginout changes it to a watch cursor.  When the
    session manager finishes initializing, it changes the cursor to
    whichever shape you have picked through customization.