Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!bionet!ames!elan!tom
From: tom@elan.Elan.COM (Thomas Smith)
Newsgroups: comp.windows.open-look
Subject: Re: XView Programming Style
Message-ID: <971@elan.Elan.COM>
Date: 27 Mar 91 20:45:09 GMT
References: <0x6u9ws@openlook.Unify.Com>
Organization: Elan Computer Group, Inc., Mountain View, CA
Lines: 99

[ regarding a discussion of whether to create popup windows at startup time
  or the first time that they are actually needed. ]

Originally (I think) awatkins@lager.UVic.CA (Andrew Watkins) writes:
> I have a bunch of popup window (~7) and
> I'm adding more all the time. At present I create all of my windows
> when the program starts up and set the visibility off for all the
> windows I'm not using.

This is one approach to creating popups (also known as dialog boxes,
depending on your favorite nomenclature).  It has the following advantages:
    + All application initialization appears in the code at the same place
    + Code updating state information in the dialog boxes can assume that
      the structures are present/allocated
However, you also may encounter the following problems:
    - Since allocation/initialization is done at the same time, there may
      be a significant delay in startup as perceived by the user (customer).
    - The worst-case scenario for resource usage (memory, cpu) becomes the
      normal case - in other words, if your application has dialogs that
      are not often used, you still pay the penalty of creating and managing
      them.

Then Larry Wake, Sun Microsystems (larry.wake@west.sun.com) adds:
> ...these windows will take time to create; they'll
> also consume X server resources and application memory.  So, why create
> them until they're first needed?  If I don't create them all at once,
> the program starts that much faster, and the time taken to create
> windows is distributed equitably throughout the total execution time of
> the program.

This is the other approach to popup window creation.  If your particular
application has many dialog boxes that are modestly sized, this is generally
a better approach to use.  For small applications it is probably not
an important decision, but as Andrew Watkins observes above, as an
application grows, its interface is usually growing as well.  What may
not be a significant performance hit today may annoy prospective customers
six months from now.

This is referred to as the "Piss-Off Factor of User Interface Design":
The approach that is least likely to piss-off the user is more likely
to sell your product.  (also known as "In the Valley, no one can hear
you scream.")

In addition to the potential saving of resources that are never needed,
you also have the option to free resources that are no longer used.
A popup window can be destroyed when it is undisplayed, if necessary.

rick@pbi.com (Richard M. Goldstein) has the following suggestion:
> somehow, i still don't think most applications of any sophistication
> would get all the way through their setup with this technique, they
> would still end up creating everything between invocation and the
> call to xv_main_loop().

Why do you say this?  A good design is one that is easily extended as
your product grows.  Both of the above approaches treat the N+1th dialog
the same as the Nth one.

> a more sophisticated technique would be to create an "object" (i.e.
> structure) that represents all of the controls on the popup and interact
> with the popup through this object.  this way, at invocation you would
> malloc() the structures and maintain a coherent "state" for the popup
> by getting/putting values into the structure.
> 
> then, on down the road when the user selects this popup off the menu,
> call to the devguide initializer and copy the contents of the corresponding
> structure into the popup and then set XV_SHOW to true.

This is actually independent of when the dialog (or managing structure)
is created.  It is more an issue of modularity.  There are two approaches
to maintaining a dialog box's display of an application's state.
  1) Pushing information:
     When a dialog box is created, initialize it with the current state
     (note that this applies regardless of the creation strategy used).
     As the application changes state, have it feed the appropriate new
     information to each (created) dialog box.
  2) Pulling information:
     When a dialog box is *displayed*, have it query the application layer for
     the current state and initialize itself.
     As the application changes state, have it trigger each
     *currently displayed* dialog box to update itself.

The second approach has several advantages:
  + It is more modular.  The code necessary to update each dialog box 
    is separated from the application layer itself.  Enhancements to the
    dialog box (new controls, extended features) thus have a limited impact
    on the application.
  + It is more efficient.  Because only displayed dialog boxes are updated,
    information is only passed around if the user can see it.
  + It is faster to implement.  The "update-me" code, which is typically
    as complicated as the "create-me" code, can be used both for initial
    displaying and for updating the state as it changes.

The moral of the story?  Some thoughtful design today can make your
product sell better in the market place tomorrow.

    Thomas Smith
    Elan Computer Group, Inc.
    (415) 964-2200
    tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom