Community
Participate
Working Groups
I20060131-0800 Double click in new history view opens compare editor while in the new open it simply opened the selected revision.
This point is interesting. Could you elaborate on why you think it is important to have the open of the contents themselves be first class (i.e. easy to do) while opening a compare be second class (i.e. need to open the context menu). Our feeling was that it was more common to want to compare your local contents to the selected revision than actually see the contents themselves.
>Double click in new history view opens compare editor while in the new open it >simply opened the selected revision. That should have read: Double click in new history view opens compare editor while in the old one it simply opened the selected revision. The problem is that the new history view is used for different work scenarios: 1) compare (e.g. via Compare With > Revision...) here indeed I want to see the comparison but not by using double-click each time but by using the single-click open strategy I defined in the preferences. 2) looking at the revision history and open a revision. Note that in 1) (when comparing revisions) I do not like to see the local history entries since I explicitly wanted to compare with a revision but in 2) it's cool to see the local history as well. This won't be possible now that 1) and 2) are folded into one view. I'm constantly changing the filter. I agree that you could have defined the comparison as first class but after years of using the old history view I'm used to look at revision by double-clicking into the history view (I think I once filed a bug that it should honour the open strategy as well ;-)
We are working towards a consolidated history. The plan is to have one Team>Show History, one Compare With/History and one Replace with/History (and one Team>Restore from History). This way the user does not need to distinguish what types of history there are. As for support for the different workflows, one idea we had thought of was a toolbar button for switching between compare mode and open mode. We are also working out how to simplify filtering out local history (parhaps a toggle on the toolbar as well). Another thing we are thinking about is adding TreeColumns to groupd changes by time. Perhaps we can use this to group the local changes so they are there but don't tak up much real-estate until expanded.
This certainly isn't intuitive, but after trying it out I like being able to compare easily. Perhaps it could follow the same pattern as the synchronize view, where left click compares the resource, and DND into the editor area performs "Open". That way either operation could be achieved with a simple mouse gesture. If there was a compare mode, it could automatically compare whenever two items are selected.
A toggle filter in the view tool bar button would definitely help since currently it needs many interactions to enable/disable local history. This would be similar to e.g. the Java Outline page where the important filters are in the view tool bar. Having a tool bar button to set the mode (open/compare) would definitely help but it should also automatically set the right mode i.e. open mode if I selected Team > Show Resource History and compare mode for Compare With > Revision.... And of course both modes should honor the open strategy I've chosen in my preferences. >This way the user does not need to distinguish >what types of history there are. Just wondering, was that ever a problem (bug report)? The more context I have the better, at least that's how I like to work, e.g. with the old compare editor I instantly see the input element (full path) to which I compare in the editor tab. Neither the new compare editor nor the history view show any information in the tab/title. In addition, the full path can't be seen anywhere in the new implementation and sometimes your lost since there's zero clue what's being compared in the new compare editor (see attached screenshot). I now also have to do more interactions than before and think up front: before I could open two compare editors via 1. select file A.java, Compare With > Revision... 2. select file B.java, Compare With > Revision... Now I must not forget that step two changes the input of the new history view i.e. I have to first pin the view, or later again go back to the Package Explorer and select A.java (the history view does not have a history itself (e.g. a 'Back' button). Interesting will also be how the compare editors behave once bug 125861 will be fixed i.e. will two different History views reuse the same compare editor and waste one that I'm still interested in since I opened it from a different (pinned) History view? >same pattern as the synchronize >view, where left click compares the resource, and DND into the editor area >performs "Open". Mmh, I didn't even know that DND worked there ;-)
Created attachment 33925 [details] picture showing lost context
Thansk for all your feedback. I think a compare toogle that is enabled/disabled by the action that populated the history view is worth trying. In regard to the extra context afforded by having separate commands for local history vs. remote history. If you extend that argument to far, you end up with a very full context menu. Having said that, combining the history commands is still under consideration. In regards to having multiple editors, I think your point is valid. Perhaps compare editors shoudl follow the same poilciy as local editors where you can set a maximum and pin or specify that you just want bew ones for everything. In regards to the loss of context, we should make sure that we show the relevant context in these places. The view shoudl show the full path of the resource in the view description and the compar editor should hava tab that shows hte resource name and a tooltip tat shows the path. A meta-comment here is that the problem that got us started on this path was that people would open a compare revision editor and then realize that the option they wanted was available only in the history view. We could keep the compare with revision editor the way it was and add the extra funtionality. However, one of the functions that users want is the ability to compare two revisions and it seems odd to launch an editor from an editor. One of the things we are planning to add to the history view is a history dropdown. This combined with the new workflow would allow the user to get back to oldr revison compares failry easily if the editor was closed or changed.
The compare toggle could have three states: enabled, disabled and automatic, in which it would infer the state from the operation that opened/activated the History view.
Here's a summary of what we put in for M5: - We've added 3 mode buttons to the History View toolbar which will allow users to select which filtering mode they want (Local + Remote, Local only, Remote only) - Users can perform comparison and replacement operations both from the history view and from the dialog (controlled by preference). - We determine what the default click action in the view is based on how it is opened. For a normal show history, the default click action is open. For a compare /replace action the default click action is compare. - Added a Compare Mode item to the toolbar drop down menu which allows users to switch click action. - We adhere to the platform open strategy. - Paths have been added to the compare editor I've created a new bug for M6 (Bug# 128462) to track compare editor opening strategy - which seems to be the one area that hasn't been touch on yet. Thanks for everyone's feedback!
Verified using 3.2 M5. The solution is almost perfect if there wasn't bug 125680 ;-)
Dani, I suspect the bug # is a typo in your last comment ... bug 125680 belongs to AspectJ Doc component.
Yes, typo. Should be bug 125860.
