Presenters, Views, and some models can implement commands. As the new
declarative linking of commands to queries using annotations has been
rolled out, it became apparent that there was duplication of code to
manage the registers of queries, menu populators, and accelerator keys
for each command target. Some of this is relatively complex, but it is
completely command so we can implement as a global register so that the
facility is easy to add to any class, regardless of whether it sits within
Presenter or view hierarchies.
By taking advantage of the nil substitution of String>>expandMacrosWith&c,
we can also easily implement a defaulting mechanism for expandable menu
text so that it is not necessary to reset this explicitly when the commands
are disabled. This was difficult to get right, and a frequent source of
minor bugs in the UI where disabled commands would appear on menus with
out of date dynamic text, or with unexpanded macro insertions. Since we
are defaulting the menu text back to its definition in the view resource
when not set by the command query, we should do the same with menu item
images (i.e. reset them to the value in the view resource if changed by
a previous command query, but not the latest query).
It is also became evident that the mechanism for providing tool tips has
similar characteristics to the old #queryCommand: (i.e. it is a based on
a value switch), and that it could generally be implemented through the
command querying mechanism anyway. The tip-text will now be the expanded
text for the command as provided by the command query. This means that
the tip-text for a toolbar button would be the same as for an equivalent
menu command if there is one, or can be set specifically for the toolbar
if the button has a unique command that is not on the menus. It is still
possible to use the old mechanism, and it should work as before for
existing packages.
Presenters, Views, and some models can implement commands. As the new declarative linking of commands to queries using annotations has been rolled out, it became apparent that there was duplication of code to manage the registers of queries, menu populators, and accelerator keys for each command target. Some of this is relatively complex, but it is completely command so we can implement as a global register so that the facility is easy to add to any class, regardless of whether it sits within Presenter or view hierarchies.
By taking advantage of the nil substitution of String>>expandMacrosWith&c, we can also easily implement a defaulting mechanism for expandable menu text so that it is not necessary to reset this explicitly when the commands are disabled. This was difficult to get right, and a frequent source of minor bugs in the UI where disabled commands would appear on menus with out of date dynamic text, or with unexpanded macro insertions. Since we are defaulting the menu text back to its definition in the view resource when not set by the command query, we should do the same with menu item images (i.e. reset them to the value in the view resource if changed by a previous command query, but not the latest query).
It is also became evident that the mechanism for providing tool tips has similar characteristics to the old #queryCommand: (i.e. it is a based on a value switch), and that it could generally be implemented through the command querying mechanism anyway. The tip-text will now be the expanded text for the command as provided by the command query. This means that the tip-text for a toolbar button would be the same as for an equivalent menu command if there is one, or can be set specifically for the toolbar if the button has a unique command that is not on the menus. It is still possible to use the old mechanism, and it should work as before for existing packages.