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. _______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
