Archive for April, 2007|Monthly archive page

How do you dish out the current obect in the context?

The environment may dish out all the possible operations that could be performed on the current object in the context to the user from different sources. It could be from the right click context menu on the current object or the cute icon in the toolbar or the menuItem in the global menu bar or a tree layout in the side bar or an icon in the tray.

The same set of operations may be offered by multiple sources. Then
Q.How can we manage to keep all of them in sync?

>The context specific menu items must be populated dynamically. They must never be cached with the current object

>All the menuItems/icons must be tagged to their associated actions , i.e, if a certain operation is disabled for the given context then all the UI components offering that particular operation must be disabled or should not be populated at all.

To achieve this, possibly you must have a registration mechanism of all the operations against the UI components offering them.

>Populate the ContextMenu with the selection oriented commands

>Populate the ContextMenu with a fixed set of comands for each selection type and then enable/disable them to reflect the selection state.

This will help the user to see an expected and same set of consistent context menu and will make navigation easier.

>The context specific menu must be consistent across all the object displayed in the editor.

>If the same object appears in more than one editor, then same contextMenu must be available.

>Classify and group the menuItems using menu separators.

>Provide the common operations on the editor itself, which are not selection specific rather than on each of the object. For eg: Reload, SelectAll, Back, Undo/Redo, Find, Zoom

Q. How can the editor cope up when the menuItems, which might possibly be contributed by a add-ons and plugins?

>There must be a registration mechanism to allow the menuItems dispayed in the editor to be registered with the HostControl.

>Implement a command filter for each object type in the editor.

Some dumb questions to ask…

>Whats the best way to provide response to the functionality from the editor but inturn being offered by different objects?

>If the functionality of an operation is provided by a specific object in the editor, then that particular functionality must be exposed as public method inorder to allow the editor to provide response to the menuItemClick.

>If for the sake of consistency, all the context specific menuItems are being populated by the editor, then the editor must be able to exactly locate and identify the current Object and must enable/disable menuItems accordingly but how to do it cleanly?

>If the effect of an operation being performed by using object1 or object2 is same, then why have functionality available from both objects?

Writing about it so far has helped me in clearing some blockages and probably would be in a better state to comment more on it once I solve it completely.