Talk:Context Menu

Put your comments there.

--Peter gummer 13:28, 8 February 2007 (CET) The mechanism looks good, and the details of the various menus appear to be well thought-out. Something I would want to see is the ability to hit the context menu key available on most Windows keyboards as an alternative to having to reach for the mouse. Another issue is that I've submitted a change request asking that the top-level "Clusters" folder in the Clusters tool be removed, because it just gets in the way; but if you did so then you would have to figure out where to put the "Add Cluster" context menu item. I don't think this is a problem, however: "Add Cluster" could simply go on the context menu of a cluster folder.

--manus 18:57, 8 February 2007 (CET)The context menu key should be supported since vision2 as a hook for it (it is the Key_menu key). For now we will address the context menu part only.

--Jocelyn 08:11, 8 February 2007 (CET) This sounds great for me, context menu will be very useful in many places. I was also wondering if we could one more way to handle the "Pick&Drop/Context Menu" For instance if we just Right_Click "Released" by default we keep the P&D mechanism, but if we keep the Right_click pressed for a moment (10ms for instance) we display the context menu. So this would allow 3 behaviors, maybe that would be too heavy, however this could be a smooth way to integrate context menu into EiffelStudio.

--manus 18:57, 8 February 2007 (CET)It was one of the initial suggestion we had but as a user I've always found waiting very annoying, I'm just faster at pressing a key and clicking at the same time rather than waiting. Anyway see the updated Context_Menu page for details.

--Ericb 08:24, 8 February 2007 (CET) In many applications that I use, the first entry in the contextual menu is in bold, and if instead of right-clicking I double-left-click I get the action of this bold entry executed. I realize that in text panels of EiffelStudio double-left-click might already be used (to select a word for example). But what about using double-right-click to get this behavior, instead or in addition to shift-right-click?

--manus 18:57, 8 February 2007 (CET) I've never seen such an application, do you have a sample? Double-right-click might not work from a user perspective, because on the first release you always show the context menu (at least this is the case on Windows), so I'm not sure from a UI behavior point of view if this is great. Another issue is that in most context menus we have designed it is quite hard to decide what should be the default action, but if we assume that this is the former double-right-click behavior then we might be able to do it, but the default entry might be at various places in the context menu and thus possibly confusing?

--Ericb 20:01, 8 February 2007 (CET) An example? Well, Windows Explorer. The default action is the one in bold, not necessarily the first entry in the contextual menu.

--manus 07:27, 9 February 2007 (CET) Is there another application that does the same? I guess so, but none of the one I use do that.

--Ericb 08:06, 9 February 2007 (CET) In WinZip, in the "Check for modifications" window of TortoiseSVN.

--Peter gummer 13:28, 8 February 2007 (CET) The double-click idea is a great one. I think that, wherever it's already used, that should be the first item in bold in the relevant context menu. This way, we conform to operating system standards. I still trip over pick-and-drop, right-clicking in other applications when I should be left-clicking. Failure to conform to operating system standards just slows users down. So double-left-click, please. (Double-right-click is already used, by the way, in EiffelStudio's editor and context tools. To target the editor or context tool to a class or feature currently referenced there, I just double-right-click on it. The Diagram tool is inconsistent in this respect, by the way, because whenever I double-right-click on a class bubble, instead of targeting the Diagram tool it complains that I am creating an inheritance cycle: oops!)

--manus 18:57, 8 February 2007 (CET)The diagram tool will be one of the most difficult tool to convert to the usage of context menu. For the first entry in the menu, I'm not sure about it, would it be ok to duplicate a menu entry then? That is to say leave the default action where it belongs (usually under the Show part for classes/features) and add a copy of this action as first entry. Note that when you don't have a pebble there is no such default action.

--Neal Lester 8 February 2007 For some pick targets, I think the "Pick" option will be called far more frequently than any others. For those "pick" targets, it might be better to simply do the "pick" then the contect menu. For those rare times when you want the context menu, the user could drag the picked object to a "context menu" target on the tool bar. Dropping the picked object on the "context menu" target would activate the context menu.

--manus 18:57, 8 February 2007 (CET)This is a good idea when you are in `pick and drop' mode, but I'm not sure if this is really needed since you have two ways of making the context menu appear: Shift + right-click and if we adopt Jocelyn's suggestion simply hold the right-click for a few seconds.

--Ericb 17:23, 8 February 2007 (CET) Peter, that's funny because I always concisdered the behavior that you described with doube-right-click as two right-clicks.

--Peter gummer 01:36, 9 February 2007 (CET) When in Context menu mode, the current plan says that, in order to initiate a pick I would have to select Pick, the first entry in the menu. This would be a little tedious for something that we do so often. The operation would involve one of the following sequences of hand movements: either (a) Right-cick, shift the mouse down and to the right a bit, and click again; or else (b) hit the Context menu key, hit the Down key, hit the Enter key. I can think of a few alternative operations that would streamline this common task. (1) Double-left-click, as described above by Eric. (2) A keyboard shortcut; e.g., F12 doesn't seem to be used. Hitting F12 again would perform the drop operation. Ctrl+F12 would open in a new window, as Ctrl+right-click currently does. (3) Drag-and-drop! Yes, believe it or not, I want EiffelStudio to conform to normal user expectations and implement drag-and-drop. I'm sick to death of accidentally hitting the wrong button in other applications because EiffelStudio has conditioned me to clicking the right button instead of the left. There's nothing pick-and-drop does that drag-and-drop can't do. The only advantage of pick-and-drop is that the user doesn't have to hold down the button while moving the mouse; well this advantage doesn't even exist any more -- at least not on Windows -- because drag-and-drop is configurable to do this too: in Windows Control Panel see the Mouse "ClickLock" setting. I would use all three of the above alternatives, although the F12 shortcut would be my favourite.

--manus 07:27, 9 February 2007 (CET) Isn't Shift+right-click a better quick alternative to perform the pick and drop? But I like the idea of using a function key (the same way the context menu key is currently used) for initiation a pick and drop.

For the drag and drop I'm not a big fan since it does not work very well with the editor, indeed are you moving the text or trying to target the current editor to the class you selected. This one of the reason why we did not have a browser style browsing in the editor and other formatters (for example, in firefox text selection is disabled using the mouse when you go over a link, you can still do it via the keys though).

--Peter gummer 13:56, 9 February 2007 (CET)

You're right: drag wouldn't work in the editor. (Although personally I never use that mechanism, some people do.) Double-click wouldn't work in the editor either, because it selects a word. So a function key or Shift+right-click would be the only possibilities in the editor. Double-click and left-button drag would still be possible everywhere else, however. I think the drag-and-drop option is very important, because it's an operating system convention. Actually, on second thought, why wouldn't drag from the editor work? If the text being dragged in the editor is a class or feature, then if I drop it into a different tool it currently does nothing -- well actually it does do something, it moves the text within the editor even though I did not drop it there, which is really dumb. So I think dragging from the editor would work after all.

--Peter gummer 01:51, 9 February 2007 (CET) Of the two or three modes that are proposed, which should be the default that new users encounter? I believe that the operating-system-compliant "Context menu" mode should be the default, since this would be the easiest for EiffelStudio newbies. An advantage of context menus is in helping new users to learn an application, right-clicking randomly on widgets and items to see what options they provide. This benefit is lost if no context menus appear when the newbie right-clicks on things. Old-time power users who want the old "Pick and Drop" mode will quickly learn how to switch back to their old preferred mode.

--manus 07:27, 9 February 2007 (CET) That was our intention, context menu is the default when installing EiffelStudio 6.0 and our existing users will be able to switch to the old behavior if they want.