Memo #22896
From: inovatronics
Date: Thu,  3 Oct 91 16:39:49 EDT
To: djunod
Message-Id: <memo.22896>
Subject: AppShell needs list

David,

Below is a list of the features which we will need or want for AppShell
to support in order to implement some of the features of AppBuilder.

Please look them over and let me know what you think.

James Nelson
INOVAtronics.

AppShell.library MUST Haves (and must NOT haves, i.e. Bugs):

1) Call into Screen Update routine (as used by AppShell's notification
   screen updating.)  Should accept new ScreenTags as parameters.  Perhaps
   have the same for palette updating (though this is not impossible to
   work around through normal system calls.)

2) Initial Screen Tags should be part of the Intui_UI tags, rather than
   the Window Environment tags, as the screen is global to all windows.
   This is not implemented as you thought during phone conversation with
   Cash Foley.

3) Call to change the attributes of a window, including all supported
   flags, and, preferably, the ability to rename the window object, this
   last feature is for internal use only.

4) What is the status of Text ID sparse numbering support in AppShell?

5) Regular Groups should be supported, all objects in the group being
   relative coordinates.  This is in the docs, but doesn't work.

   Related: Group creation should be less order dependent.  If this
    can't be done, let me know as soon as possible.  AppBuilder should
    allow order independent adding of Groups and Gadgets within the
    groups.

6) Better Function-Gadget relationships.  This is the problem I reported
   on BIX that only one Object which is associated with a Function gets
   properly updated when the Function is ENABLED/DISABLED.  You commented
   that you are going to change this, but I just wanted to request it for
   the record.

7) Relative Positioning doesn't seem to work properly.  Do you need examples
   of this?  Also, relative positioning breaks down when certain gadgets are
   ADDED to the window through the AppObjects.library.

8) Ability to prevent a projects FONT type from being taken from the
   prefs: this is primarily an AppBuilder problem, as we need it to
   run under TOPAZ 8 only, unless the problems noted at DevCon can be
   worked around.

9) TEXT TABLE equivalent tags for OBJ_MX lists and OBJ_Cycle lists.  Currently
   these are coming from static arrays of strings.  You had suggested that
   you would provide a tag which would contain the TextID of a string such
   as One|Two|Three, which would attach to the MX or Cycle gadgets correctly.

10) Some Gadtool gadgets have tags to call functions (such as slider output).
    We need either a Appshell tag equivalent pointing at a function in
    the function table (if possible) or we can only specify the source name
    when defining these tags.  What do you this is the proper approach?

AppShell.Library REALLY Wants:

1) Ability to specify in the Intui_UI tags a set of window environments
   for the project to register, rather than just one.  Windows in this list
   would be specified to open on startup, or to remain closed until a
   WINDOW OPEN command.  SNAPSHOT could store this information as well, so
   that a project can have a complete startup configuration.  Currently
   only the first window opens on startup.  Other reason for having this
   is that until a window is attached, the WINDOW commands do not know
   about it.  If it can be defined in startup tag list, the application
   should not have to open it through consecutive calls to HandlerFunc.

AppShell.Library SHOULD haves:

1) The ability for a window to be "ShutDown" rather than just closed,
   causing the window to be passed NEW data to reopen it.  In
   other words, it returns to a state in which AppShell doesn't know that
   the window has ever been created: as in prior to a call to HandlerFunc.
   Memory is being wasted keeping track of windows that may never be openned
   again.

General Needs:

1) Please send us the source for the simple Image Editor which you already
   have.

2) We need a method for determining the size of created GadTools Gadgets, so
   that our Gadget Cursor can correctly size over them.  At present, a user
   can enter 0,0 for the width and height of a MX gadget, yet the gadget will
   be different in size depending on the number of items in the list.
