Messages again

[John Darrington]

Here's my current thoughts on message handling for the GUI.  I'm
sharing these here,  because they might be general enough to be of
interest to other front-ends.


1. There'll be a new construct, which I'll call a "message context".
   Each message context contains a double ended queue of messages.
   Each context has its own message reporting policy. The policy can
   decide that: 

   * Messages are reported FIFO.

   * Messages are reported LIFO.

   * Only the most recent message is reported.

   * Messages are not reported at all.

   etc.  Further, a context can specify the manner in which messages are
   reported, eg: dialog box, scrolled list, log file or combination
   thereof.

   More complicated policies could decide to handle different
   classes/severities of messages differently if necessary.

2. The GUI will have a stack of message contexts.  At any time, the GUI
   may push a new context onto the stack or pop the top one from the
   stack.  As  messages arrive, they get  entered into the queue of
   the top-most message context.  When a context is popped from the
   stack, the queue is destroyed and all messages forgotten.


3. When the queue of the top-most context is not empty, and the
   reporting policy is FIFO, there'll be an idle callback to dequeue
   messages and report them. Except that messages musn't be
   reported with dialog boxes  whilst a global pointer or keyboard
   grab is active. 


My rationale for this system is to allow sensible message reporting in
situations where errors are expected and non-fatal. Eg: partially
entered dates in cells such as "04-July-1776" raise errors until the
complete string is entered.