We currently have a machinery implemented in Composer (and to a lesser extent in other components) for the dispatch of user commands, and the maintenance of command state. For details of how this works in Composer, see <http://www.mozilla.org/editor/editor_commands.html>. I'm currently not clear on where the dividing line falls in the embedding world, between tasks that the embedder must perform, and those that are handled by the embedded Mozilla components. For example, are we expecting the embedding application keeps track of which commands are enabled or not, and relies on notifications from, say, composer to say that the enabled state of a command changed? Or can we make use of the command state maintenance machinery that is already there (though much of it is in XUL/JS, and would need a C++ imlementation), and treat the embedder more like a thin UI layer? For example, what should UpdateCommands() do in the embedded case, or does that lie in the realm of something that the embedder needs to implement? Essentially I'm looking for a much stronger description of what the emebdding APIs need to look like for a command-heavy application like Composer. Simon -- Simon Fraser Entomologist [EMAIL PROTECTED] http://people.netscape.com/sfraser/
