Talk:History behavior
--Ericb 17:23, 27 March 2007 (CEST): One thing that I don't like with the history mechanism in EiffelStudio and other tools is that it's not always the oldest item which is removed from the list. Let's consider that I looked at classes A, B , C, D in that order. The history will look like that:
A B C D
^
If I then go backwards to look at B again (using the history navigation means):
A B C D ^
and then decide to look at class E, then C and D will be removed from the history, even though I looked at them more recently than A:
A B E
^
I find this situation very annoying. In a tool that I wrote, I implemented a history mechanism where only the items to the left of the history (i.e. the oldest) are removed. It is probably not a standard behavior, but I find it more convenient. It works as follow. Let's consider that I have:
A B C D ^
and want to look at class E, then my history will look like that:
A C D B E
^
B has been moved forward because that's the class I was just looking at, and then E has been added. That way I don't lose C and D, they are still in the history, still accessible using the history navigation means. Likewise, if I then drop class C in my tool, the history will look like that:
A D B E C
^
I find it more convenient than:
A C D B E ^
because C is really the most recent class that I looked at.
--manus 22:56, 27 March 2007 (CEST) EiffelBench implemented something like that, but we dropped it partly because it was confusing. Moreover the fact it is not standard behavior might not be a positive point for certain people. However something we could do is preserving the back and forth button behavior (i.e. acting the same way as in your web browser) and changing the dropdown to list the most recently used items first and then the history (the way it is done in some of Microsoft tools for style/font selection). What do you think?
--Ericb 00:39, 28 March 2007 (CEST): Do whatever you want, but don't throw away recent items before older ones. I must say that I really like the way the history works in my tool (as described above), despite not being standard. It is very convenient and I don't find it confusing at all. To the contrary, it is less confusing than having items disappearing from the history just because I clicked a couple of times in the back button before dropping a new class. This behavior is not acceptable to me. It's not a question of confusing or not, but of acceptable or not. I don't think that history should work like a undo/redo mechanism. But the impression that I get from EiffelStudio's history is exactly that: a undo/redo mechanism, not redone actions are lost when executing a new action.
--Ted 04:42, 28 March 2007 (CEST): I don't like the way items are thrown away neither, so I had an idea I called it Insertion mechanism. As long as one think it the way editing the text at inserting mode, it is easy to understand. It works like this:
A B C D
^
A B E C D
^
Time items are inserted or visited is also tracked, and the oldest one will be removed when a new item is inserted. I know that this mechanism also breaks the standard way. By any means, not throwing away recent items is contradictory to the standard behavior, because the standard does. The reason I don't like Eric's is that moving items around is really confusing, at least for me, and I would rather keep it as what it is.
-- larryl 05:09, 28 March 2007 (CEST) Visual Studio 2005 has the same history behavior as the last behavior Ted described. I think that one it the best one so far.
--Ericb 11:20, 28 March 2007 (CEST): Sorry, I still prefer the behavior I described. The behavior described by Ted is not satisfactory to me because E is more recent than C and D, so it should appear to the right of these two classes. Otherwise E will be removed (at some point) from the history before C and D, even though it is more recent. The behavior that I described is not something that I came up with one morning when waking up. I gave it a lot of thoughts. It is the result of several trials and corresponds to what is the more useful for me in practice, while not that confusing after all (at least not for me) compared to other solutions.
--Ted 11:48, 28 March 2007 (CEST): E will not be removed before C and D. I said the time E inserted is tracked, so the structure in fact does not anymore fully represent a sequence in time.
--Ericb 14:27, 28 March 2007 (CEST): If you don't call this behavior "confusing", what do you call it?
--Paulb 20:02, 28 March 2007 (CEST) Okay, so here it is. The Visual Studio mechanism works very well but the issue with Visual Studio is that it does not have a real history. Visual Studio navigates documents using CTRL+TAB, which we have in EiffelStudio. In Visual Studio it is very effective and behaves in a similar manner to what Eric is describing. In addition you cannot open a previous opened and closed document, like you can with the EiffelStudio history.
To explain the process you need to consider that an open document cannot have it contents replaced by another document, as with EiffelStudio. Opening a file will always create a new tab (I wish ES could be configured this way, as do others)
For the initial open documents, start with A through D. D will be the last opened.
A B C D
Using CTRL+TAB to access the history an select B would yield a history
A C D B
B is moved from it previous position an placed at the end. This would also be true if you attempted to reopen B. It's logical that D was used prior to B so hitting CTRL+TAB once would flip back to D.
A C B D
If the user wants to got two steps back they'll press CTRL+TAB, release TAB and press TAB again. Pressing TAB twice (same as ALT+TAB in Windows.) would end up with C as it's two positions back.
A B D C
You see C is now at the end next to D, which was opened last.
If A is then closed the history is as such
B D C
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:
A B C D
^
Press back twice
A B C D ^
Press forward once
A B C D
^
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. Eric approach although effective to himself because he knows the internals, will actually be confusing to those that don't. The same holds true for Ted method of insertion.
Neither approach works on their own. There are two approaches we can take. One with the current mechanism of being able to swap documents or the other without swapping. Without swapping is much easier to implement.
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 exampling, let's start with A through D again.
(OH) A B C D
(VH) A B C D
^
(RH) A B C D
Press back once
(OH) A B D C
(VH) A B C D
^
(RH) A B D C
C is move in OH and RH and placed at the end.
Press back once again
(OH) A D C B
(VH) A B C D
^
(RH) A D C B
B is move in OH and RH and placed at the end, after the last viewed C.
Press forward
(OH) A D B C
(VH) A B C D
^
(RH) A D B C
C is move in OH and RH and placed at the end, after the last viewed B.
Close A, without switching to it using the X on the tab.
(OH) D B C
(VH) A B C D
^
(RH) A D B C
A is removed from OH because it only maintains the history for opened items. All other histories are unaffected.
Now using CTRL+TAB switch to B.
(OH) D C B
(VH) A B C B
^
(RH) A D C B
You see that B now appears twice in the VH. D has also been removed from VH because changing the past events affect the future. Always note that OH and RH switched to class at the right most of the history.
Now open a new class E
(OH) D C B E
(VH) A B C B E
^
(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 preference that is strict in a tab-per-document, i.e. not swapping permitted.
1. 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 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!
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 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.
2. Without swapping:
Without the ability to swap documents the VH back and forth buttons would act globally. That is switching to any opened tab that hosts the history item or opens a new tab if the history item is associated with a closed document.
The rules for RH are the same as using the VH.
I don't have time right now to read or join the conversation, but I found this analysis of web browser navigation interesting.
--Ted 04:34, 29 March 2007 (CEST) 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:
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.
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.
