Conference bulova::decw_jan-89_to_nov-90

    Folks smarter than me will undoubtedly answer the harder questions, but
    since I'm here first let me answer one.
    
    "Normal applications" (use your own definition of this) should create
    exactly one widget of class ApplicationShellWidgetClass.  This class
    uses the argv argc passed on the command line.  The application name is
    used to specify all the leftmost part of the full name for widget resources.
    
    All other top level widgets should use TopLevelShellWidgetClass which
    is just like applicationShell without the semantics for argv, argc and
    the widget resource specification root.
    
    TopLevelShell creates a new root of a widget tree. ApplicationShell
    creates a new root of a widget tree _and_ a new root for the resource
    data base.
    
    re: unrealized TopLevelShells and realized popups: From the old
    conference it was never clear to me if this was the Intrinsics
    Specification-conforming behavior or whether it was an artifact of the
    Digital implementation.

The application that I am working on creates multiple topLevelShells.  It
gets the applicationShell widget from XtInitialize and then ignores it.  This
is because all of the topLevelShells are equal.  We don't want to special case
the dismissal of one of the them.  Instead, ALL widget heirarchies are children
of the topLevelShells and the application shell from XtInitialize remains
unrealized.

Dick

    First, XtInitialize is considered obsolete in Xt Intrinsics R3.
    
    The R3 way of accomplishing the same thing is
    	XtToolkitInitialize
    	XtCreateApplicationContext
    	XtOpenDisplay (a convenience routine of
    		XOpenDisplay
    		XtDisplayInitialize)    		
    	XtAppCreateShell
    
    But, of course, the old (R2) method is supported.
    
    Second, if the user passes command line arguments to the application
    then you ignore them (as opposed to applying them to all shells), right?
    
    Finally, the topLevelShells you create are popup children of the
    applicationShell (as opposed to opening several display connections),
    right?

The 64K question is:

  Does repeated invocations of "XtToolkitInitialize" cause undesirable 
  side-effects or does the routine detect a second call and simply return?

If the answer is not the latter, then we have no improvement over the
status quo, and writing modular procedures will be no easier than with 
the old XtInitialize.

James

    "The semantics of calling XtToolkitInitialize more than once are
    undefined"
    
    Identical wording appears in both the MIT and VMS DECwindows Toolkit
    Routines Reference Manual.

Not to start the discussion about modularity again, but not being able
to determine when to call and not to call XtToolkitInitialize will cause
us big problems. Our product must run as a complete subsumed runtime library
which independently uses an X display. It is a requirement that we be able 
to be called from an application program which may already be using the Xt
toolkit. We can not however be sure that this application is always using the
toolkit since we may be the applications only method for interacting with the
screen. Since calling XtToolkitInitialize will cause some unspecified and 
potentially harmful action, we obviously may not call that routine EVER. As 
such, we are left with the choice of:

 1) Always call XtToolkitInitialize, document this behaviour, and require that
    any application which also wants to use the toolkit make a call to our entry
    before it makes a toolkit call. (This won't please TPU very much since they
    anticipate making their own call to XtToolkitInitialize. And I agree they 
    should fully expect that they can build self-contained code!)

 2) Not support any application which calls the toolkit since we can not be 
    sure who initialized the toolkit. This is unrealistic, we recognize there
    exists a set of applications which will want to use both tools directly.

 3) Not support DECwindows. Do I need to explain why this is not an option?

 4) Never call a toolkit routine, do everything with Xlib, forget that we've
    (digital) has invested 2-3 years of work in the toolkit and do everything
    by hand. - Similarly, do I need to justify why this is unrealistic?

In short, the cop-out approach of "It's hard, let's just make it undefined..."
doesn't work when you try to build modular software. I'd be happy if the answer
was:

  ``The second and succeding calls to XtToolkitInitialize have no affect on 
    the state of the toolkit.''


James McCartney
DECforms Development

> screen. Since calling XtToolkitInitialize will cause some unspecified and 
> potentially harmful action, we obviously may not call that routine EVER. As 
> such, we are left with the choice of:
>1) Always call XtToolkitInitialize, document this behaviour, and require that
>   any application which also wants to use the toolkit make a call to our entry
>   before it makes a toolkit call. (This won't please TPU very much since they
>   anticipate making their own call to XtToolkitInitialize. And I agree they 

not to mention

  5) Always require the application to call XtToolkitInitialize before
     calling you;

  6) Have your calling application pass you a parameter indicating they
     have already initialized the toolkit;

and there must be other combinations.

I'm not sure DECwindows is something you work with or work around, but it's
the wave of the future.  Maybe there is a positive solution that hasn't
been mentioned yet.

  John

Does this quote from the VMS 5.2 release notes help the situation any?

  "4.9.1  Changes to the DECwindows Toolkit
         
          In VMS Version 5.2 of the DECwindows tookit, you can
          initialize both the Intrinsics and DRM as many times 
          as the application requires.  This is an extension 
          of the MIT R3 Intrinsics and should not be used by 
          applications that want to remain R3 compatible.  This
          change has been proposed to the X Consortium for 
          inclusion in R4."


Or are we talking about something else?

RE:

not to mention

  5) Always require the application to call XtToolkitInitialize before
     calling you;

  6) Have your calling application pass you a parameter indicating they
     have already initialized the toolkit;

and there must be other combinations.

RE: 5) This is extremely non-modular, an application program that is primarily
concerned with how it gets a payroll database written by a programmer that 
has never seen or heard of DECwindows is not the sort of place you want to 
start spreading Xt calls around. This type of approach is stictly in violation
of separation of form and function. Furthermore it restricts the application
to a single class of terminal. DECforms is designed such that the application 
does not need to be aware of ANY details of the device on which information 
is to be displayed/gathered. The FORM is the location in which the details of
the device and the mechanisms for handling user interactions are stored. Having
to make the toolkit visible and also making the initialize call dependent upon 
knowing the device is a workstaiton is exactly what we don't want to do.

RE: 6) This is an option, however, it still violates the design rules that have
been decided by the ISO/ANSI FIMS committee, namely that the application program
need not be aware of the details of the device on which it will interact. The 
idea is that transactions between the application and the form are requests for
data not necessarilly request to update the screen. How the form presents the 
information to the user and how the user enters the requested data is controlled
in the form, as written by the form designer. The intent is that the SAME 
application be able to (without knowning specifics) interact with either a 
workstation, a character cell terminal, a printer, or a DECtalk w/o knowning 
the specifics of how the device is to be controlled. The application should 
not need to know, for instance, the details of when to call toolkit routines,
or what escape sequences need to be generated.

RE:


  "4.9.1  Changes to the DECwindows Toolkit
         
          In VMS Version 5.2 of the DECwindows tookit, you can
          initialize both the Intrinsics and DRM as many times 
          as the application requires.  This is an extension 
          of the MIT R3 Intrinsics and should not be used by 
          applications that want to remain R3 compatible.  This
          change has been proposed to the X Consortium for 
          inclusion in R4."

Excellent! I had not seen confirmation of this. This is exactly what we need.
Thanks.

James

How about an approach like GKS has supplied?  Have 2 (or more) different ways
to get things going.  The first is the normal GKS initialization.  It assumes
that the application knows nothing about X or DECwindows.  The second is
DECwindows specific and allows an application to supply information about
the display and window/widget heirarchy to work under.

Dick

.4> such, we are left with the choice of:
    (followed by 1,2,3,4)
    
.9> RE: 5) This is extremely non-modular, an application program that is primarily
    (etc.)
.9> RE: 6) This is an option, however, it still violates the design rules that have
.9> been decided by the ISO/ANSI FIMS committee, namely that the application program
    (etc.)
    
    Your points are well-taken, but my point was there were options other
    than the ones you raised in .4.  As near as I can tell it ultimately
    comes down to a conflict of standards -- to obey one set of rules is to
    disobey another.  One wonders how much concern the architects had for
    these kinds of problems.
    
      John