Difference between revisions of "Context Menu Mechanism"

Latest revision as of 13:15, 9 April 2007

Initial Mechanism

The mechanism for providing contextual menus in EiffelStudio will come from a modification of the Pick and Drop mechanism. By doing this it will give a lot more control when it comes to integrating the technology as we need to give full access to the existing Pick and Drop mechanism via the Context Menu. This is because at first not every potential pebble 'drop' will be possible via a menu entry due to the hundreds of possibilities/commands Eiffel Studio currently has and using the Context menu may or may not be the quickest way to achieve this for an advanced user. EiffelVision currently does not expose the pick and drop mechanism so that it may be performed manually so having everything set up via Vision2 and passed to a handler seems to be the best approach for now as it involves the least amount of work and testing for providing the mechanism. Future work could go towards abstracting the mechanism from the widget implementation itself and having an external mechanism perform the pick and drop work as this would remove a huge amount of code and be much easier to manage/test.

Initial Implementation

The initial mechanism we have is for every possible pebble source, we set the mode from its current (default) pick_and_drop_mode to configurable_target_menu_mode via the call 'set_configurable_target_menu_mode'.

Approach could be automated but would need design change of command widget factories

I had originally envisaged that each potential pick and drop target for a given pebble would give enough detail to be able to construct a context menu automatically as each menu item in the context menu should relate to a single pick and drop pebble target, I added code to be able to retrieve the menu data (text and pixmap) for a pebble target. To construct a hierarchical menu the PND target name for a given pebble would mention the hierarchy (such as "Show / Descendents") In theory, every command should be able to take a pebble, for example when you select text you may be creating a selection pebble which fits in the cut copy and paste command targets. However the docking mechanism introduction made this task more difficult as none of the droppable targets are no longer descendents of EV_PICK_AND_DROPABLE so Vision2 has no notion of them (they were via deferring the drop actions from the parent and so are hidden from the mechanism) This makes an automatic approach not very practical without a redesign of the command factories SD_* classes, so this means the menus will probably have to be hard-coded.

Hard Coded Approach

To EV_PICK_AND_DROPABLE, which is the source of every PND pick, I have added set_configurable_target_menu_handler. What this does is allow an agent to be passed that is called by the configurable target menu mechanism when right clicked over a valid pebble.

The signature is as follows

PROCEDURE [ANY. TUPLE [a_menu: EV_MENU; a_target_list: ARRAYED_LIST [EV_PND_TARGET_DATA]; a_source: EV_PICK_AND_DROPABLE; a_pebble: ANY]

 a_menu: EV_MENU
   - Menu built by mechanism that already has an initialized 'Pick' entry that allows reversion to the existing PND mode'.
 a_target_list: ARRAYED_LIST [EV_PND_TARGET_DATA]
   - List of meta data of all potential targets for the given pebble
 a_source: EV_PICK_AND_DROPABLE
   - Object where the PND began.
 a_pebble: ANY
   - Pebble in question.

This way when a context menu is requested by the user (via right clicking or Menu key (not yet implemented)) the menu will already be initialized with the 'Pick' option already added to 'a_menu'. This way we can just customize the menu by adding to it.

ES_CONTEXT_MENU_FACTORY

By adding an agent callback to each of the PND sources, we should be easily able to create menu items relating to certain ES commands that are relative to the pebble in question. We can add an ES_CONTEXT_MENU_FACTORY that has a once agent routine that is passed to all of the pnd sources.