Talk:History behavior - Revision history

Peter gummer at 09:45, 1 April 2007

2007-04-01T09:45:09Z

Larryl at 03:40, 30 March 2007

2007-03-30T03:40:08Z

Larryl at 02:28, 30 March 2007

2007-03-30T02:28:45Z

Larryl at 02:08, 30 March 2007

2007-03-30T02:08:57Z

Larryl at 02:06, 30 March 2007

2007-03-30T02:06:00Z

Paulb at 16:44, 29 March 2007

2007-03-29T16:44:41Z

Ted at 02:34, 29 March 2007

2007-03-29T02:34:17Z

Neallester at 21:56, 28 March 2007

2007-03-28T21:56:43Z

Paulb at 18:23, 28 March 2007

2007-03-28T18:23:44Z

Seilerm: typos

2007-03-28T18:17:28Z

typos

← Older revision		Revision as of 09:45, 1 April 2007
Line 230:		Line 230:
	-- [[User:Larry\|larryl]] 04:06, 30 March 2007 (CEST) I have made two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS.		-- [[User:Larry\|larryl]] 04:06, 30 March 2007 (CEST) I have made two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS.
	I have sent the videos to Paul's email.		I have sent the videos to Paul's email.
		+
		+	--[[User:Peter gummer\|Peter gummer]] 11:45, 1 April 2007 (CEST) Regarding the discussion about Ctrl+Tab in VS, I'd like to point out that this was the thing that annoyed me most about VS 2002 and VS 2003. My brain does ''not'' maintain a stack of files that I have been working on. The way Ctrl+Tab worked in VS 2002 and 2003, it might as well have been switching to a random file: sometimes I can't even remember the ''last'' file
		+	that I looked at, never mind the ''second'' last. Even after using VS every day for two years it still irritated me. VS 2005 has improved this by giving me visual feedback of where it's about to switch to, and I'm very pleased that EiffelStudio has adopted this approach. My preference, however, would be for Ctrl+Tab simply to switch to the next tab to the right, like the Windows "Display Properties": Delphi always worked like this, and I always found it extremely easy to use: I didn't have to waste my limited brain space trying to guess where Ctrl+Tab would take me, because the tabs were there right in front of my eyes.
		+
		+	But is Ctrl+Tab really relevant to this history behaviour? Paul wrote above that VS has no history cursor. But it does, and it's one of my favourite features in VS! Hit Ctrl+Minus: VS takes you to the last place the cursor was. Then hit Ctrl+Shift+Minus: VS returns you to where you were before. This is very close to what we are discussing here.
		+
		+	By the way, one thing that's always annoyed me about Alt+Left and Alt+Right in EiffelStudio is that it does ''not'' remember cursor movements. I usually move around a class text by Page Up or Page Down, etc. It's really irritating to hit Alt+Left, only to be taken to the top of the class text rather than to where I was.

@@ Line 228: / Line 228: @@
 As a side note, Eclipse supports a real history but do not allow documents to be swapped.
--- [[User:Larry|larryl]] [[User:Larryl|Larryl]] 04:06, 30 March 2007 (CEST) I have made two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS.
+-- [[User:Larry|larryl]] 04:06, 30 March 2007 (CEST) I have made two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS.
 I have sent the videos to Paul's email.

@@ Line 228: / Line 228: @@
 As a side note, Eclipse supports a real history but do not allow documents to be swapped.
--- [[User:Larry|larryl]] [[User:Larryl|Larryl]] 04:06, 30 March 2007 (CEST) I have uploaded two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS.
+-- [[User:Larry|larryl]] [[User:Larryl|Larryl]] 04:06, 30 March 2007 (CEST) I have made two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS.
-[[Media:ABCDE and TwoHistoryNoRelation Demo]]
+I have sent the videos to Paul's email.

← Older revision		Revision as of 02:08, 30 March 2007
Line 229:		Line 229:

	-- [[User:Larry\|larryl]] [[User:Larryl\|Larryl]] 04:06, 30 March 2007 (CEST) I have uploaded two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS.		-- [[User:Larry\|larryl]] [[User:Larryl\|Larryl]] 04:06, 30 March 2007 (CEST) I have uploaded two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS.
−	[[~~File~~:ABCDE and TwoHistoryNoRelation Demo]]	+	[[Media:ABCDE and TwoHistoryNoRelation Demo]]

← Older revision		Revision as of 02:06, 30 March 2007
Line 227:		Line 227:

	As a side note, Eclipse supports a real history but do not allow documents to be swapped.		As a side note, Eclipse supports a real history but do not allow documents to be swapped.
		+
		+	-- [[User:Larry\|larryl]] [[User:Larryl\|Larryl]] 04:06, 30 March 2007 (CEST) I have uploaded two videos to demonstrate two questions. One is when we have ABCD history, then go back to C, insert E. VS will INSERT (not remove any history point) E after C. Another demonstrated question is that "Back and Forth" and "Ctrl + Tab" have no relation in VS.
		+	[[File:ABCDE and TwoHistoryNoRelation Demo]]

@@ Line 83: / Line 83: @@
 A no longer belongs to it. As I said, this is not a real history.
-With the VS mechanism, using the back and forth buttons, you would only be able to switch between the two last opened documents. This can be remedied by using a cursor as Eric described in his approach of using a cursor. That is:
+END OF VS METHOD DESCRIPTION.
   A B C D
@@ Line 98: / Line 100: @@
+      ^
-What happens when you open a new document now. Current described rules dictate that it should appear after D. I say no. When you navigate back in a history and new changes at that point wipe out the future. That is to say:
+What happens when you open a new document now? Current described rules, by others in this discussion, dictate that it should appear after D. I say no. When you navigate back in a history, any new changes at that point wipe out the future. That is to say:
   A B C D
@@ Line 221: / Line 223: @@
 And I also found that VS also takes cursor positions as history records. Once a tab is closed, all that page related history records are removed.
 All above I am talking about is VH.

← Older revision		Revision as of 02:34, 29 March 2007
Line 197:		Line 197:

	I don't have time right now to read or join the conversation, but [http://www.cosc.canterbury.ac.nz/andrew.cockburn/web_navigation.html I found this analysis of web browser navigation interesting.]		I don't have time right now to read or join the conversation, but [http://www.cosc.canterbury.ac.nz/andrew.cockburn/web_navigation.html I found this analysis of web browser navigation interesting.]
		+
		+	<b>--[[User:Ted\|Ted]] 04:34, 29 March 2007 (CEST)</b>
		+	Swapping or not doesn't really matter to me when I am using VH. What I am interested in is the text displayed in front of me is the one I needed, no matter how the tool handles it.
		+	I didn't know how VS worked until Larry posted, and I tested in VS, I found this described by Paul is suspicious:
		+
		+	<i>
		+	What happens when you open a new document now. Current described rules dictate that it should appear after D. I say no. When you navigate back in a history and new changes at that point wipe out the future. That is to say:
		+
		+	A B C D
		+	^
		+
		+	Now we open E
		+
		+	A B C E
		+	^
		+
		+	D is wiped out, just like undo/redo.
		+	</i>
		+
		+	The result should be:
		+	A B C E D
		+	^
		+	And I also found that VS also takes cursor positions as history records. Once a tab is closed, all that page related history records are removed.
		+	All above I am talking about is VH.

← Older revision		Revision as of 21:56, 28 March 2007
Line 193:		Line 193:

	The rules for RH are the same as using the VH.		The rules for RH are the same as using the VH.
		+
		+	--[[User:neallester\|neallester]]
		+
		+	I don't have time right now to read or join the conversation, but [http://www.cosc.canterbury.ac.nz/andrew.cockburn/web_navigation.html I found this analysis of web browser navigation interesting.]

@@ Line 182: / Line 182: @@
 * Prompt the user to switch to the open tab. This is going to get annoying because what if there are other history items that you have to navigate past, that have their documents open in other tabs. You would be prompted for each one!
-So, I my mind, there is no nice solution.
+So, in my mind, there is no nice solution.
-I discussed this with Julian and Martin and the only solution visaged would be to allow the same document to be opened in the editor. Martin actually wants this behavior because there is no way to edit the same document in two places using a vertical split editor, like most editors have. Allowing the same documents open multiple will enable this. However the multiple tab editor will need to modified to abstract the view from the underlying buffer so modifications are synchronized between the views.
+I discussed this with Julian and Martin and the only solution visaged would be to allow the same document to be opened in the editor. Martin actually wants this behavior because there is no way to edit the same document in two places using a vertical split editor, like most editors have. Allowing the same documents open multiple will enable this. However the multiple tab editor will need to be modified to abstract the view from the underlying buffer, so modifications are synchronized between the views.
 For the RH, selecting an item would either switch to an already open document or replace the current tab with the selected unopened document.

@@ Line 81: / Line 81: @@
   B D C
-A no longer belongs to it. As I said, this is not a real hitory.
+A no longer belongs to it. As I said, this is not a real history.
 With the VS mechanism, using the back and forth buttons, you would only be able to switch between the two last opened documents. This can be remedied by using a cursor as Eric described in his approach of using a cursor. That is:
@@ Line 114: / Line 114: @@
 You need to maintain three separate histories. You need an open/viewed document history that monitors what tabs are opened and switched to, I'm calling the Open History (OH). This would behave in exactly the same manner as Visual Studio, as described above. The other history is implemented using a cursor and works for the back and forth buttons, I'm calling the Visit History (VH). The difference between OH and VH is that VH maintains items that have closed as well as hosting similar history items. In addition VH will track both switching of classes and features. The thrid and final history I'm calling the Recently Used History (RH), for the history combo box. RH is like OH but maintains closed items.
-To examplin, let's start with A through D again.
+To exampling, let's start with A through D again.
   (OH) A B C D
@@ Line 173: / Line 173: @@
   (RH) A D C B E
-Now this history is outlined the semantics of VH and RH need to discussed with respects to the multi-tabs editor. Currently EiffelStudio supports swapping open document tabs with different content. I also propose that we have a prefernece that is strict in a tab-per-document, i.e. not swapping permitted.
+Now this history is outlined the semantics of VH and RH need to discussed with respects to the multi-tabs editor. Currently EiffelStudio supports swapping open document tabs with different content. I also propose that we have a preference that is strict in a tab-per-document, i.e. not swapping permitted.
 . With swapping:
 Now we have multiple tabs maybe the VH back and forth history should only pertain to the active tab, just like multiple-tabbed web browsers. An issue is that you could navigate back in a tabs history to open the same document that is already opened in another tab, which should not really be permitted. There are three solutions to this
-* When reaching that history item, switch to the opened tab. However with localized tab history what's the concequnece of swithing to a new tab? Does the switched to tab history take over? It shouldn't because that's not the history the user was navigating through. That would be the only viable option unless you really want to mess up the history trying to do overly complex tracking.
+* When reaching that history item, switch to the opened tab. However with localized tab history what's the consequence of switching to a new tab? Does the switched to tab history take over? It shouldn't because that's not the history the user was navigating through. That would be the only viable option unless you really want to mess up the history trying to do overly complex tracking.
 * Skip or remove the history item if it's open in another tab. But this creates an incomplete history.
 * Prompt the user to switch to the open tab. This is going to get annoying because what if there are other history items that you have to navigate past, that have their documents open in other tabs. You would be prompted for each one!
@@ Line 184: / Line 184: @@
 So, I my mind, there is no nice solution.
-I discussed this with Julian and Martin and the only solution visaged would be to allow the same document to be opened in the editor. Martin actually wants this behavoir because there is now way to edit the same document in two places using a vertical split editor, like most editors have. Allowing the same documents open multiple will enable this. However the mutliple tab editor will need to modifed to abstract the view from the underlying buffer so modifications are synchornized between the views.
+I discussed this with Julian and Martin and the only solution visaged would be to allow the same document to be opened in the editor. Martin actually wants this behavior because there is no way to edit the same document in two places using a vertical split editor, like most editors have. Allowing the same documents open multiple will enable this. However the multiple tab editor will need to modified to abstract the view from the underlying buffer so modifications are synchronized between the views.
 For the RH, selecting an item would either switch to an already open document or replace the current tab with the selected unopened document.