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. And once we are able to drag and drop within EiffelStudio, I would like to drag and drop a class from EiffelStudio into an external editor: I wanted to do just this a few minutes ago. And we could drag and drop class files from Windows Explorer into EiffelStudio. This is standard behaviour in most high-quality applications, and I want it in EiffelStudio too!

--manus 19:18, 9 February 2007 (CET) I have a few questions for drag and drop in the editor. (1) If no text is selected and you start clicking on a class, how do you know the user wanted to do a drag and drop or a selection operation. (2) If text is selected, I suppose that the whole class name is selected, how do you distinguish between moving the text in the editor and actually doing the semantic action of retargetting the editor. (3) If we drag outside the editor instead of moving the text, how can one scroll the document to drop the text somewhere else.

--Peter gummer 00:13, 10 February 2007 (CET) (1) If no text is selected and you left-click on a class in the editor and then start dragging, then I think it would have to behave just as it does now: i.e. it would start selecting text. I don't see any way around this, and I wouldn't try to find a way around it because my main hope is that EiffelStudio will conform to the standard behaviour of the operating system. What it's doing now is standard, so I would leave it alone. (2) If you drag and drop a whole class name within the editor, it would simply move the text as it does now. You might tell it to re-target the editor by, say, holding down the Shift key, but that would be awkward and unintuitive. (3) Ok, I didn't know it did that; I never use this technique. Now that you mention it, looking at other applications I see that this functionality is pretty common. EiffelStudio's implementation of it, however, is poor, because the drag cursor remains enabled well beyond the edge of the editor widget -- even beyond the bounds of EiffelStudio itself, to the edge of the screen. This is misleading to the user, because if I drag over some other widget or application, the drag cursor should change to indicate that I am not allowed to drop the text there. Instead, it's behaving as if the cursor is still over the editor. Compare this with, say, the Visual Studio editor, which does this properly; I can make the the Visual Studio editor scroll by placing the mouse just beyond the edge of the editor, over the tab at the top or the scroll bars at the right or bottom or over the margin at the left, but if I move the cursor a bit further then it stops scrolling and it correctly indicates whether I'm allowed to drop the text. Therefore, the answer to question (3) is easy: fix this bug! I'll submit a problem report for it now.

--manus 00:42, 10 February 2007 (CET) For (3) we also use an acceleration scheme and the further away from the editor, the faster it scrolls. Doing the same in visual studio is quite slow since you have to be exactly at the border to scroll.

--Peter gummer 08:45, 10 February 2007 (CET) Visual Studio 2005 has an acceleration scheme too. It's fast: it just scrolled through a 5,500-line file for me in under twenty seconds. Any faster and it would be impossible to see when to stop. Visual Studio's acceleration scheme seems to be based on the length of time you leave the cursor at the edge of the editing area, rather than how far you move it beyond the edge. I think this is a much better idea, because EiffelStudio's approach is misleading if it was not your intention to scroll.

--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.