Conference bulova::decw_jan-89_to_nov-90

    (1) The user is the best judge of what is "allowed".
    
    (2) There is little or no relationship between the steady-state number
        of windows and performance.
    
    (3) Window creation and widget creation take time but it's a small
        matter of programming to create them before they are needed and map
        them, which is a fast operation, as they are needed by an
        application.
    
    	The actual widget content may not be predictable, but its class and
        position in the widget hierarchy should be predictable.
    
    (4) Limiting what a user can do is a session manager function.  I'm
        standing in line myself with everyone else waiting to know what the
        full story is for session-manager customization user-implemented
        session managers.
        

I agree that the creation of windows does not take much time, but
starting 'heavy' applications together might become a problem in some
cases , as is iconized windows who should be on the screen instead of
on the icon box (this could be arranged by using a mod.dialog box as a
parent).
For user-customized session managers...is there something done allready ?
I replaced the session manager by a end-user application and that
restricts to the use of one and one application only. But this is
more a trick then a strategy and I only did it for personal use.
Dominique

    Pat,
    
    	It is reasonable in certain environments that "the best judge
    	of what is allowed" is *not* the user.  The prefix to the
    	question clearly spells out such a environment... say a
    	fission reactor monitoring system.  And there *is* a relationship
    	between the potential for deadlock (see the SCS note) and the
    	number of clients and activity on the workstation.  For (say)
    	this environment it might be valid to only allow a static set
    	of applications to be active, some *always* active and to disable
    	entirely the session manager.  *This is **not** a "desktop" system*.
    
    

    
    Why should removing or replacing the Session Manager be a "trick",
    it sounds like the appropriate thing to do in a bounded system
    such as you describe, as opposed to a general desktop system
    that the software is setup for.
    
    

The session manager is the tool by which the user controls what applications
are using the workstation.  So if you don't want the user to control that, 
a logical approach would be not to run the session manager at all.  Instead,
start up the applications some other way, and have them create the windows
they want.

The window manager is the tool by which the user controls where windows
are positioned, whether they are occluded, and whether they are iconized.
If you don't want the user to control what the display looks like in any
way, the logical thing to do is not to run the window manager at all, but
rather have the applications position their windows where they want them.

	paul

That the X and Decwindows development groups recognized that they should provide
mechanism and not enforce policy is the very thing that makes it appropriate in
this situation. Nowhere is it cast in stone that you *must* start either the 
session manager or the window manager. In fact it's quite easy to *not* start
them. So, for your application, I would suggest that you just start the server,
then start your process monitoring application and let it talk directly to 
the server - no window manager, no session manager etc. The style of the monitor
won't be exactly like that of other DECwindows Applications, but as pointed out
in an earlier reply, this environment isn't a "desktop" application.

There are various points of compromise in between, like starting only the 
window manager w/o the session manager, or even starting your own custom 
window manger. There are several window managers available in the public 
domain that you might be able to start from - uwm, twm, awm and MGR (the
Bellcore window manager) - all available from a USENET archive site.

If the business is strategic to Digital, I'm pretty sure that the DECwindows
group would listen to a presentation as to what was needed in a custom WM
and if profitable, a mechanism for building the custom WM could be worked.

Actually, since I have no direct association with the group, I can only suggest
that this be the approach to getting the functions you need. I can NOT make
any commitment relative to your desired functions in the window manager.

In short, the answer is not to just "Roll you own." but "Take the parts that
you can use, omit those that do something you don't need, and provide what is
still missing youself."

James McCartney
DECforms Development

I pretty much agree with James in .6, although I would expand a bit, I guess:

If you wish to do rather specialized things that are related to window positioning
and focus and the like, making a specialized window manager is probably the
way to go.  Actually, the window manager could be written to limit the number
of (top level) windows put on the screen.  It is the window manager that
maps all of these windows, after all.

Similarly, with a specialized application, you may well want to do without
the session manager.  You have to deal with issues like logging in and
security set up, but there is no reason you HAVE to use the session manager.

As to us listening to requests for customization features:  Sure, we will listen
to anything (depending on how you define listen).  The official method for
making suggestions, though, is the Phase 0 process.  Paul Steeves (STAR::) is
the product manager who should get that kind of request (although we are coming
to a close of P0 for the next version).

Burns

    That's what I'm talking about when I talk about notes that can draw
    fire.  Basically, I agree with the replies others have written.
    
    re: 207.1, I'll withdraw (1) for certain process monitoring
    applications.  Fred surely knows (2) the performance impact of mega-windows
    better than I.  I guess my comments on (3) widget recycling and (4)
    user-written session managers stand as is.
    
    Having seen more third party and customer applications that determine
    screen geometry and just map the entire screen than human endurance could
    provide for, I guess I'm full of knee jerk reactions to claims that the
    application should take control of the screen from the user.