Difference between revisions of "Talk:History behavior"

Revision as of 04:27, 28 March 2007

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