Hi Mark,
> No. The task just knows that applications may issue annotations,
> and yes it ought to structure its menus with that in mind. But in the
> kind of case we're talking about here it has no knowledge, at any
> stage of the interaction, about what any of these annotations (if there
> are any) mean. The user selects one of the available options, and
> the sending app blindly passes the annotation along to the recieving
> app. Any message parameters, return values etc are treated precisely
> the same at the sending end regardless of which annotation, or whether
> any annotation at all, is selected.
I think I understand: Task A posts a message with an annotation and Task B creates a menu entry, if the user selects that entry then that message is sent back to Task A as the command?
As it's being used currently I'll admit it's clever, but how do we describe this in the spec? The problems I see are that
In the first case the spec would need to identify 'process.table' as the special message type and prescribe some sort of behavior an application should take as well (but only when it sees the annotation?). Why not just use a more explicit 'gui.addMenu' message to instruct the app, the args to that message could then be variable and be returned just as they are now (we could even have a syntax that says '$F' in the arg string should be replaced with the file name).
Are there use-cases for annotations besides creating menus that couldn't likewise be handled with a special mtype?
Cheers,
-Mike
Received on 2007-05-03Z15:43:27