Conference bulova::decw_jan-89_to_nov-90

    
    I define/exec/table=decw$logical_names winmgrexe "Syste$system:hpwm.exe"
    within SYSTARTUP_V5.COM (not SYLOGICALS because I'm pretty sure that
    decw$startapps is executed afterward.
    
    Andy

    
    If you really want to make this transparent, try something like:
    
    	$ copy sys$system:hpwm.exe sys$system:decw$winmgr.exe
    
    1/2 :-) (and many thanks to Bruce Mann)

re: <<< Note 841.1 by 43248::LESLIE "Andy ��� Leslie, CSSE" >>>
    
> I define/exec/table=decw$logical_names winmgrexe "Syste$system:hpwm.exe"
> within SYSTARTUP_V5.COM.

Thanks for the reply.  I put that as the *last* line in my systartup_v5 file

$ define/exec/table=decw$logical_names decw$winmgrexe sys$system:uwm.exe

and.... nothing.  It gets overwritten by (apparently) startapps and
when I finally get a chance to login it is back to decw$winmgr.exe.

re: <<< Note 841.2 by STAR::BRANDENBERG "Si vis pacem para bellum" >>>

> $ copy sys$system:hpwm.exe sys$system:decw$winmgr.exe

Oooh.  Thats DIRTY!!!   ;-0

DECwindows gets started up in 

SYS$STARTUP:VMS$CONFIG-050_VMS.COM and then again in 
VMS$LPBEGIN-050_STARTUP.COM after it calls SYSTARTUP_V5.com

have fun...

						.dave.

re: <<< Note 841.5 by POOL::MARRA "Acts 2:4" >>>

> DECwindows gets started up in 

> SYS$STARTUP:VMS$CONFIG-050_VMS.COM and then again in 
> VMS$LPBEGIN-050_STARTUP.COM after it calls SYSTARTUP_V5.com

Yes.  I found that out this morning after poking around.  But
I don't understand what it means, or how I can modify what
happens in decw$startapps.com...  Can you suggest something?

Thanks.

It is not acceptable to have to play with system-wide startup files to select
an alternate window manager.  Window manager selection is a user preference
feature.  A non-privileged user must be able to select the window manager that
they want to use.  The window manager doesn't actually get started until session
login occurs.  Couldn't LOGINOUT or the Session Manager handle firing up the
correct window manager based on something from Xdefaults, SYSUAF.DAT, or some
other sort of persistent repository of user customization information?

--PSW

> It is not acceptable to have to play with system-wide startup files to select
> an alternate window manager.

That is why I asked (in a tounge-in-cheek way) if this was WM wars, cause
the developers seem to have gone to great lengths to prevent anyone from
using anything other than the Decwindows WM.

Still, I don't see anything wrong with using startup files to select a
*default* window manager system wide.  But I agree that is should *also*
be user selectable.

Finally, I was really asking about customizing *anything* that is done in
decw$startapps.  It seems to be impossible in 5.2 without resorting to
editing decw$startapps itself, or resorting to the trickery mentioned in
previous replys.

Dear Developers:  Have ye anything to offer to us?  Why can this not be
placed in DECW$XDEFAULTS?  Afterall the WM is started by some code that
is ``windows-aware'' right?

re: .7

I agree.  I wouldn't think it would be that much work to move the code from
DECW$LOGINOUT.EXE where I beleive the window manager is started from, and moving
it to DECW$SESSION.EXE where it could read in DECW$SM_GENERAL.DAT and be a
customizable item.


Sean

> I wouldn't think it would be that much work to move the code from
> DECW$LOGINOUT.EXE ... to DECW$SESSION.EXE where it could read in 
> DECW$SM_GENERAL.DAT and be a customizable item.

Except that the SM is the *last* thing to be started, after all the stuff
in decw$login.com, etc...  What I was hoping was that decw$loginout could
load the RESOURCE_MANAGER property of the root window (say with XGetDefault)
and start the WM based on that.  Actually, I think many other customization
features should be done here, because it is disconcerting to seen windowpop up
with one appearance, and then, when the SM *finally* gets started, to see the
appearance change as customizations get effected.

The session manager starts up right away in the user process.  It just does 
not create its window until all the other work is done.

The window manager was intentionally started up in loginout in order to speed
up the login process.  This has its penalties...

Burns

RE: <<< Note 841.11 by 19458::FISHER "Burns Fisher 381-1466, ZKO3-4/W23" >>>

> The session manager starts up right away in the user process.  It just does 
> not create its window until all the other work is done.

Gee Burns, I hate to disagree, but, judging from this excerpt from my
decw$sm.log, that is not true:

$	set noon
$!
$! Discover who we are
$!
$	Display = f$trnlnm("DECW$DISPLAY")
$	DNumber == f$extract(3,f$locate(":",Display)-3,Display)
$	set process/name=decw$session_1
$	write sys$output "I am DNumber 1 on display WSA1:"
I am DNumber 1 on display WSA1:
$!
$! Start applications
$!
$	spawn/nowait/input=nl:/output=decw$banner.log/proc=decw$banner_1 -
$	  run sys$system:decw$banner
%DCL-S-SPAWNED, process DECW$BANNER_1 spawned
$!
$! Thats all.
$!
$	Exit
$ !
$ ! DECW$STARTSM.COM - Initialize the DECwindows session manager
...
$ ! This command procedure sets up the DECwindows session manager
$ ! development environment. 
$ ! It is not advisable to edit this procedure as it may be replaced in
$ ! future software updates. 
$ !
$! if no command files executed, then status will be blank
$!
$if $status .EQS. "" then goto do_session
$!
$! if status is ok, no errors in command procedures, so start session manager
$!
$if  $status then goto do_session
$do_session:
$define decw$doing_session T
$run sys$system:decw$session
Session Message: Started DECterm controller 

$!
$! log out and delete the logical
$!
$do_exit:
$if f$logical("decw$doing_session") .NES. "" then deassign decw$doing_session
$logout
  WITHROW      logged out at 30-MAY-1989 15:42:52.77

RE: .12

First, it appears that you like to ignore warnings like the one included in 
DECW$STARTSM.COM:

``$ ! It is not advisable to edit this procedure as it may be replaced in
  $ ! future software updates. 
  $ !
  $$do_session:''

Second, I believe that Burns was talking about the actions of the IMAGE not 
the COMMAND PROCEDURE. Namely that piece of code started at the:

``$ run sys$system:decw$session''

So given the SUPPORTED files shipped from DECW engineering, what Burns says
is true.

James

re: <<< Note 841.13 by IO::MCCARTNEY "James T. McCartney III - DTN 381-2244 ZK02-2/N24" >>>

> First, it appears that you like to ignore warnings like the one included in 
> DECW$STARTSM.COM:

Sorry, but you have jumped to a false conclusion!  The first part of the
decw$sm.log that I posted comes from the results of my
sys$login:decw$login.com and the second part comes from 
sys$manager:decw$startsm.com.  I DID NOT EDIT DECW$STARTSM.COM!!!  It appears
that these two command files are run in succession in the same process,
and that this is caused by either decw$loginout.exe or loginout.exe *after*
it $CREPRCs the WM.

> Second, I believe that Burns was talking about the actions of the IMAGE not 
> the COMMAND PROCEDURE. Namely that piece of code started at the:
> ``$ run sys$system:decw$session''

The above line is in decw$startsm.com.  As I explained above, this line is
executed *after* the stuff in decw$login.com, and *not* before.

> So given the SUPPORTED files shipped from DECW engineering, what Burns says
> is true.

Sorry, but I still think he is mistaken.  Additionally, as I have seen the
same statement in several other places in this conference, perhaps lots of
folks are mistaken.  Alternatively, perhaps there is some way to cause
a time warp in vms, that I don't know about, that will allow a .log file
to contain lines to appear non-monotonically WRT time.  In that case I
would be mistaken.

We're all right!  Actually, I was not reading your stuff quite carefully
enough and was thinking of a different issue.  In fact, loginout,
DECW$LOGIN.COM, and the session manager are all in the same process.  (Loginout
changes its process name and characteristics).   DECW$LOGIN is certainly
run before the session manager image starts, but the image itself is what
starts the terminal and vue (in future versions, other applications can
be started too).  After starting these applications, then it creates its
window.

Sorry for the confusion.

Now we just have to figure out exactly when the resource files are read in.
That was a real problem because when loginout goes away, the server may
reset and wipe out the resources, and yet you want the window manager to
see them.  I don't remember the final resolution.

Burns

> In fact, loginout, DECW$LOGIN.COM, and the session manager are all in 
> the same process.  (Loginout changes its process name and characteristics).
> DECW$LOGIN is certainly run before the session manager image starts, but 
> the image itself is what starts the terminal and vue (in future versions, 
> other applications can be started too).

Is it a supported use of DECW$LOGIN.COM to start applications?  The
documentation leads me to believe that it is.  If it is in fact supported,
then I believe it is a bug that the results of customization are applied
*after* the applications have displayed their windows, rather than before.

Also, it is a customization option that yields the terminal and vue, and the
user can elect to have neither started by the session manager.  This is,
I believe, supported.  I think I remember that the documentation shows how to 
start vue via command files (such as decw$login) and so the above situation
can occur even with vue.  Personally, I start my terminal using Child (which
is not supported, but an equivalent will be supported in the future) and
it has the same problem.

I realize that there is a kind of chicken and egg problem, but I have come
to believe that one of the following would be at least a partial solution.

  a) Start the session manager first, so that all cusomizations get loaded,
  but perhaps deferring the mapping of its window until after decw$login has 
  run.

  b) Use the suggestion in my prior note to have decw$loginout load the
  appropriate properties into the root window.

At any rate, I think there should be a supported way for the *user* to select
his window manager.

> Now we just have to figure out exactly when the resource files are read in.
> That was a real problem because when loginout goes away, the server may
> reset and wipe out the resources, and yet you want the window manager to
> see them.  I don't remember the final resolution.

Empirically, I think the following is happening:

  (decw$)loginout loads certain properties in the root window that get
  used by the SM image.

  (decw$)loginout starts the window manager.

  (decw$)loginout disconnects from the server.

  (decw$)loginout launches decw$login and decw$startsm...

The reason I think this is that if you delete the WM in your decw$login
the server resets and looses all properties, causing the SM to barf when
it gets loaded.