Conference bulova::decw_jan-89_to_nov-90

RE:                <<< Note 2014.0 by CASEE::CLARK "Ward Clark" >>>
          -< Session Manager's application definitions, menu & auto-start >-


>>    1.  Why don't all the OOTB applications appear by default in the
>>        Session Manager's Applications menu?

    Probably *just because*...  It's real easy to modify the app menu.

>>    2.  Is there policy for/against layered products adding their
>>	*definitions* during VMSINSTAL?

    Don't know...

>>    3.  Likewise, how about augmenting the Applications menu during
>>	layered product installations?

>>	(I realize that users who have customized their Applications menu
>>	won't see the new applications, but I'm sure that it's just a SMOP
>>	to fix this.)

>>    It seems to me that updating the Session Manager's "database" (resource
>>    files) during VMSINSTAL would save a lot of redundant work by System
>>    Managers and/or end-users.

    Well I think that this would be a little difficult to do.  The session
  manager resource files are not in one location for everyone.  Each user
  *may* have their own copies of these files in there own directories.

    Kitinstall.com would have to find all the user directories and then 
  check the directories for the presence the resource files and then modify
  the files.  If it were to just modify the files in SYS$LIBRARY then
  only NEW users would get the updates.

					-=> Jim <=-

I too found this capability very attractive upon switching to V5.3.  In fact,
it was the availability of these extensions to the Session Manager that
prompted me to switch from V5.2.

However, there are some other considerations.  At this time, I have my auto-
startup bringing up applications such as Bookreader, NOTES, Mail, Calendar,
a DECterm, and even the Calc component of DECdecision.  These are the 
applications that I spend almost all of my time in.  It was very easy to add
them to the Session Manager's Application list and then auto-start them.
Unfortunately, very few of them understand any kind of automatic startup.  I
can "customize" mail and calendar to start up iconized.  (Thank you)  
Supposedly, I can do the same for DECdesion, but if there are any open windows
on the screen when Calc starts up, it seems to leave its window active on the
screen instead of shrinking it to an icon.  But, all of the other applications
come up on the screen and do not offer the ability to be started iconized!
What a mess!

(=:  A PLEA TO ALL DECwindows APPLICATION DEVELOPERS - PROVIDE A CUSTOMIZE
(=:  OPTION TO START THE APPLICATION ICONIZED!

However, this is only a cosmetic problem.  Some applications actually deal 
with files that I would like to organize in sub-directories.  Unfortunately,
if you start them up from the Session Manager, they put everyting in
SYS$LOGIN.  That makes for one big mess!  It would also be nice to specify a
default directory as a part of adding the application definition to the 
Application Menu or Auto-Startup.  In the case of Calc, I coded a command
procedure to use as a shell.  But, this seems like something that could be
done for me by Session Manager as a startup option.

Lastly, I tend to like to organize things.  Rather than letting my applications
place their icons at random locations within the menu bar, I have a preferred
organization.  That means that each time that I log into my workstation, I
have to manually reorganize the automatically started up icons.  I'm not sure
how it could be done, but I sure would like some way to save the icon placement
information so that the auto-startup brings up my applications and has my
icon box layed out in the way that I want.

Yes, I really do like the ease of use of this feature of Session Manager.  It
makes it a real pleasure to use.  No more coding startup commands in LOGIN.COM!

    We are developing a product and package, ALL-IN-1 DESKtop for VMS
    DECwindows, which requires the features described in .0.  That is we
    want to add a series of applications to the applications menu for the
    users when our product is installed.  The reason is that the users for
    the product are assumed to be totally nontechnical.  Even adding an
    application is too technical for the target users.  Clicking it to be
    autostarted is the limit and our goal.

    It would be great if there were some method as Ward describes in his
    point 3 of .0.  This would be great if it were done a manner similar to
    the way FileView adds applications.

    We are thinking about making modifications to the
    [DECW$DEFAULTS.SYSTEM]DECW$SM_GENERAL.DAT file so that, at least, new
    users will get the suite of applications predefined.  

    I assume that adding our own file over the existing one is a poor idea
    given the potential for changes from version to version. We are
    thinking of adding the application definitions to the existing file. 
    This exposes us to the loss of the definitions on a new version but
    doesn't SEEM too dangerous, other than that.

    How sane does this appear?

    Looking forward to all of your opinions (I love abuse :-),

    don

FileView already addresses the problems of adding and changing menus to conform
to the currently installed versions of layered products.

Just thought I'd mention it.

-steve-

The ease with which you can run applications from the Session Manager and the
ability to auto-start them was a significant achievement!  I agree with the
other comments that we need some automatic way to expand the list when a product
is installed.

I understand the problem where each user has their own environment files that
lets them customize their view of the world.  In fact, that is a must!  But,
could you open the local user's definition file and a system wide definition
file?  If the user wants to remove an application, a reference can be placed
in the user's file to reflect that fact, therefore the system definition wouldn't
get added to the pull-down menu list.

    RE: .3 "we are thinking about modifying decw$sm_general.dat"
    
    Don't do this. DECwindows already provides a way to do what you
    want by allowing layered products to cleanly add things to the
    FileView applications menu. Work is in progress to better
    integrate FileView application definitions and the Session 
    Managers definitions.

    Re: .3  (using FileView, instead)

    We are already adding our applications to FileView using their
    excellent approach.

    Re: .6  (Don't jump)

    I'm happy to hear that better things are coming.  We certainly don't
    like to hack at internal files.  However, we have a market requirement
    to allow our nontechnical users have our applications autostart if they
    wish.  

    Another approach would be for us to create a table driven
    DECW$LOGIN.COM which does the autostart.  This seems slightly better
    than the hackery but also like inventing a new wheel.

    Thanks for the inputs.  Any other would be great, of course.

    don

    .3> DECwindows already provides a way to do what you want by allowing
    .3> layered products to cleanly add things to the FileView applications
    .3> menu.

    I realize that FileView supports application registration.
    Unfortunately, only a few people that I work with use FileView.

    On the other hand, almost everyone is using the Session Manager V2
    application features.  Auto-start seems to be the major drawing card.
    I wrote .0 because it seems unfortunate that adding new applications
    has to be done by each and every user.

    .3> Work is in progress to better integrate FileView application
    .3> definitions and the Session  Managers definitions.

    That's good news.  It would probably be a good idea to include the
    forthcoming ACA Services V2 in the integration effort.  They'll also
    need some form of application registration.

    -- Ward

It seems potentially hazardous to assume that any time a particular application
is installed, it's definition should appear on the Auto Start menu.

Workstations contain vastly different memory/processor configurations.  A 
decision to place a couple of CPU-intensive applications on the Auto Start 
could completely bury a VAXstation 2000 with 6 meg that normally runs all 
applications on another node of the cluster and uses it's own CPU merely as a
window manager.

	- Dave

Rather than adding applications to AutoStart, just add them to the Applications
menu and ask the user (what a concept) if they want it autostarted.  The option
of local or remote operation would be really nice.

Wook

I use the application start facility quite a bit.  However, I use NONE of the
standard definitions.  I have thins set up to run detached or remote.  I would
be happy to have new applications added to the list of definitions which could
be added to my application menu, but I DON'T WANT THEM PUT IN MY APPLICATION
MENU.  It already extends to the bottom of the screen.

Dick

Yes, I make extinsive use of the AutoStart feature of the Session Manager.  And,
I have even more applications added to the Session Manager's Application Menu.
However, these tend to be applications that either have good controls over their
"home" directory such as DECwindows Mail, or have no directory affiliation such
as VAXnotes.  All other applications fall under FileView so that I can invoke
them while positioned to the proper directory and against the desired file.

So, keep both application environments around.  It might be nice to make them
a little more common in the way that you integrate applications though.  But
definitely, they both have their place.

I also agree that all applications installed on the system should not be auto-
matically added to the AutoStart list.  In fact, I don't think that anything
more than the default FileView should be automatically placed there.  It should
be up to the user to select applications from the Application Menu to be Auto-
Started.  That is an easy enough operation and a part of the personalization of
that person's account.

    
    It is probably a good idea to 'redesign' the DECwindows session
    manager, in view of the capabilities offered by the Motif menu
    system.  The DECwindows SM is an added overhead in the Motif 
    environment. The 'Print Widget' is probably the only useful
    item for those using Motif today, because the 'Screen Print'
    utility is hard-wired into the session manager.  It is probably
    time to liberate the 'Print Screen' utility, so users can place
    it wherever they want to.
    
    Kris..                   

    Our cluster was just upgraded to VMS5.3, bringing with it the lastest
    and greatest DECWindows (unless you are field testing 5.4).  Anyway, I
    was quite excited about the new Application option on the session
    manager, and the ability to customize and add applications of our own. 
    Unfortunately, I am having a problem that I figure out.  I've searched
    this conference about an hour to no avail.  With 2000+ notes, I very
    well may have missed it.  Anywho...
    
    I would like to add some applications that were not intended to open
    their own DECWindow.  The closest I have gotten is to have the
    requested window to pop up, and then disappear.  This has happened with
    a few different applications, but let me give an example setting up
    VWSLAT to run through an applications call:
    
    In "Customize Applications Definitions", I have created a menu item
    named "LAT", and I have tried the "Menu Command" to be:
    
    CREATE/TERM/WINDOW(ROW=10,COL=30,TITLE="Lat Process",ICON="LAT")           
       @DECW$TOOLS:LAT.COM                                             
    CREATE/TERM @DECW$TOOLS:LAT.COM                                            
    CREATE/TERM RUN DECW$TOOLS:LAT.COM                               
    CREATE/TERM RUN VAXINE$DUB4:[DECW$TOOLS]VWSLAT                             
    CREATE/TERM/PASTHRU @DECW$TOOLS:LAT.COM                              
    CREATE/TERM/NOHOSTSYNC @DECW$TOOLS:LAT.COM                                 
    @SYS$LOGIN:TESTLAT.COM         <-- this commandprocedure has
                                       CREATE/TERM @DECW$TOOLS:LAT.COM in it.
    CREATE/TERM/DETACH @DECW$TOOLS:LAT.COM
    
    I think that I tried a few other combinations, but with no luck.  The
    window keeps appearing and disappearing, except for the /detach
    attempt, which nicely created a window, but did nothing else (which was
    expected, but I was desparate)
    
    Guess what...I just answered my own question, but I thought that I
    could enter this reply anyway (since I spent soooo long writing it, and
    since others could benefit from it):  The missing qualifier in all the
    above commands was  "/WAIT".  Without it, the "Mailbox process" seems
    to have finished all it had to do, and "logged out", while the spawned
    "TWA" process was just trying to start.
    
    Happy computating,
    
    John

    I had a similar problem. See note 2320 and replies for more
    (background) info and the solution.
    
    ---markus---

I'm starting to thingk we should have made "/WAIT" the default for
CREATE/TERMINAL.