Talk:Context Menu - Revision history

Peter gummer at 07:45, 10 February 2007

2007-02-10T07:45:57Z

Manus: Added comments on scrolling.

2007-02-09T23:42:02Z

Added comments on scrolling.

Peter gummer at 23:13, 9 February 2007

2007-02-09T23:13:22Z

Manus: fixed indenting

2007-02-09T18:18:29Z

fixed indenting

Manus: Added drag & drop question

2007-02-09T18:18:12Z

Added drag & drop question

Peter gummer at 12:59, 9 February 2007

2007-02-09T12:59:41Z

Peter gummer at 12:56, 9 February 2007

2007-02-09T12:56:20Z

Ericb at 07:12, 9 February 2007

2007-02-09T07:12:01Z

Manus: added more responses

2007-02-09T06:27:06Z

added more responses

Peter gummer at 02:23, 9 February 2007

2007-02-09T02:23:14Z

← Older revision		Revision as of 07:45, 10 February 2007
Line 52:		Line 52:

	:::::'''--[[User:Manus\|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.		:::::'''--[[User:Manus\|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.
		+
		+	::::::--[[User:Peter gummer\|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.

	--[[User:Peter gummer\|Peter gummer]] 01:51, 9 February 2007 (CET)		--[[User:Peter gummer\|Peter gummer]] 01:51, 9 February 2007 (CET)

← Older revision		Revision as of 23:42, 9 February 2007
Line 50:		Line 50:

	::::--[[User:Peter gummer\|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.		::::--[[User:Peter gummer\|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.
		+
		+	:::::'''--[[User:Manus\|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.

	--[[User:Peter gummer\|Peter gummer]] 01:51, 9 February 2007 (CET)		--[[User:Peter gummer\|Peter gummer]] 01:51, 9 February 2007 (CET)

← Older revision		Revision as of 23:13, 9 February 2007
Line 48:		Line 48:

	:::'''--[[User:Manus\|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.		:::'''--[[User:Manus\|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.
		+
		+	::::--[[User:Peter gummer\|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.

	--[[User:Peter gummer\|Peter gummer]] 01:51, 9 February 2007 (CET)		--[[User:Peter gummer\|Peter gummer]] 01:51, 9 February 2007 (CET)

@@ Line 47: / Line 47: @@
 ::--[[User:Peter gummer|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!
-::'''--[[User:Manus|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.
+:::'''--[[User:Manus|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.
 --[[User:Peter gummer|Peter gummer]] 01:51, 9 February 2007 (CET)

← Older revision		Revision as of 18:18, 9 February 2007
Line 46:		Line 46:

	::--[[User:Peter gummer\|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!		::--[[User:Peter gummer\|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!
		+
		+	::'''--[[User:Manus\|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.

	--[[User:Peter gummer\|Peter gummer]] 01:51, 9 February 2007 (CET)		--[[User:Peter gummer\|Peter gummer]] 01:51, 9 February 2007 (CET)

@@ Line 44: / Line 44: @@
 :'''--[[User:Manus|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).
 --[[User:Peter gummer|Peter gummer]] 01:51, 9 February 2007 (CET)

← Older revision		Revision as of 07:12, 9 February 2007
Line 24:		Line 24:

	:::'''--[[User:Manus\|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.		:::'''--[[User:Manus\|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.
		+
		+	::::'''--[[User:Ericb\|Ericb]] 08:06, 9 February 2007 (CET)''' In WinZip, in the "Check for modifications" window of TortoiseSVN.

	--[[User:Peter gummer\|Peter gummer]] 13:28, 8 February 2007 (CET)		--[[User:Peter gummer\|Peter gummer]] 13:28, 8 February 2007 (CET)

@@ Line 19: / Line 19: @@
 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?
-:'''--[[User:Manus|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?
+:'''--[[User:Manus|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?
-:'''--[[User:Ericb|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.
+::'''--[[User:Ericb|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.
 --[[User:Peter gummer|Peter gummer]] 13:28, 8 February 2007 (CET)
@@ Line 37: / Line 39: @@
 --[[User:Peter gummer|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.
 --[[User:Peter gummer|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.

← Older revision		Revision as of 02:23, 9 February 2007
Line 39:		Line 39:

	--[[User:Peter gummer\|Peter gummer]] 01:51, 9 February 2007 (CET)		--[[User:Peter gummer\|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. ~~One of the biggest~~ 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.	+	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.