Community
Participate
Working Groups
I think it would be valuable to have panel that shows the history of what actions the developer took. Yes, there is the history tab which shows which files the developer has recently viewed. That is nice, but has some limitations. First, I hear people (I just finished a user study) tell me that they want to know which method they were looking at in addition to which file. (See bug#221082.) Second, if you are using the Auto-pin tweaklet with a restricted number of tabs, then having per-tab history is really nice. (More on tabbing behaviour from me in a few days...) Third, the file history is not timestamped. I find myself saying sometimes, "Shoot, I was looking at that right before my meeting five hours ago... what was that file?" Most importantly, the file history only shows file open/viewing actions. There are a bunch of other actions which might be interesting. + Runs. When did I do a run? In particular, I see people being uncertain as to whether they ran in debug mode or not. ("The breakpoint wasn't hit. Maybe I wasn't running in debug mode. I'd better run it again.") It would be nice to see not just when you did a run, but which run configuration and debug/not. + Edits. Which file(s) did I edit and when did I edit them? + Searches. What did I search for? Did I use File Search or Java Search? Was it a case sensitive search? + CVS check-ins. (Yes, you can get some pieces of the above information from various places. But it isn't in one place, easy to find.) Note that Photoshop has a history that is so complete that you can revert to any previous state with it. I suspect that we will never be able to do that with Eclipse, as there are some non-reversible actions, but we might be able to get close. IMPLEMENTATION Now, as far as implementation goes, you might be able to use the Mylyn monitor as a starting point. It does log a lot of stuff -- but not everything, and sometimes it logs things twice. Me, I would not try to do everything all at once. My suggested order would be 1. Timestamped Class/method views. Bonus points if you can incorporate Mylyn degree-of-interest to decorate the class/method names. Even more bonus points if you can show which methods were revealed by scrolling. 2. Timestamped edits (once per method -- don't show me that I type "t", then "h", then "e"). 3. Timestamped runs. 4. Timestamped searches. 5. Everything else. ;-) FRINGE BENEFITS One thing that having this history would buy you, in addition to making it easier to see what you'd done, is the ability to retroactively find Mylyn task boundaries a bit better. If you forget to create a new Mylyn task, or decide later that what you're working on is different enough to warrant a new task, it's hard to retroactively make something a task. With the history, you might be able to do so.
Uh, I should mention that at this point, I don't think this is a terribly high priority enhancement request. Unlike bug#221081, which IMHO could do a lot of good with very minimal effort, I think this could do a moderate amount of good with quite a lot of effort. I just wanted to get the idea out there. (I am currently analyzing data from a user study; I expect to come back in a week or two with harder stats on how often developers redo something and how much time that costs them.)
Moving to Platform
4.0 candidate perhaps?
Ducky: as you point out Mylyn has the full log of commands that are executed. Izzet Safaer, also from UBC SPL, leveraged this for providing the user the ability to rewind interaction histories (bug 146125): http://www.cs.ubc.ca/~isafer/taskboundaries/taskboundaries.html If someone is interested in prototyping this, you could take the parts of Mylyn's interaction history that you want (e.g. commands and edits) and display them in a view as suggested above. Btw, I vaguely recall that MS Visual Studio has a history view that will allow you to capture commands that you're doing in order to replay them later, in a sort of macro style.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
