Community
Participate
Working Groups
It would be nice if we had a checkbox to "do nothing" on reaching the end while comparing (perhaps only displaying a text "end reached" anywhere).
Does it mean that the End reached dialog is not enough in your opinion? I think that you can always close it (or say "No" when ask to proceed with next element/start from the beginning) which will be equivalent to "do nothing" :)
The background is that I don´t like when a search starts over from the beginning again. Hey, I´ve been there, so I don´t need to see the changes again =) I don´t want the dialog to be shown at all, so if I had this option I could tick it and also check "remember" the first time it appears. The next time when the search reached bottom, no dialog would appear. I hope I could clarify what I want?
One more question Lars, just to make sure I do understand your intention: With "Do nothing" checkbox on I would limit navigation only to the element you're comparing at this moment. Also, there would be no way of moving to the next/previous element (file) if there were any. When reaching end (or beginning) I would disable Next Change/Difference (or Previous Change/Diff) and display only a message in the status line that the end (beginning) of the current element has been reached. This is how I see it, will you be happy with this kind of solution?
Exactly =)
This is related to bug 170168.
Created attachment 77887 [details] Proposition of modifications 001 I added "Do nothing" checkbox button do ComparePreferencePage and to "End reached" dialog. Moreover added enablement of next/previous diff/change buttons to TextMergeViewer#updateControls() as Tomek propose.
The patch doesn't cover the problem in the bug report. The option "Do nothing" doesn't show when e.g. I'm comparing file with its history. AFAIS it works only when I want to sync more than one file with a repository. I would think about one patch fixing both Bug 195495 and Bug 170168. I think that we can't fix the Bug 195495 completely without fixing Bug 170168.
Created attachment 78174 [details] Proposition of modifications 002 Patch fixes this problem. Moreover contains fix for bug 170168.
THe patch has conflicts with HEAD. Please fix it.
Created attachment 80939 [details] Patch 002 refreshed to head
I'm sorry, but I need to give a "-" to the latest patch, even though it seems to works fine at the first look. However, I took a look at the code and I got some concerns: * In comment 3 I mentioned it would be nice to have an information in the status line about reaching the end (beginning) of the current element. I can't find it in the patch * Krzysztof introduces a new IPropertyChangeListener added to CompareUIPlugin.getDefault().getPreferenceStore() which is redundant, comparing to the fPreferenceChangeListener which is already there * I'm not an expert here, but I think the disposal can be handled in handleDispose, no need for an additional listener here I'll take over this bug, and take a second look on Krzysztof's patch. I'm pretty sure that with some adjustment it can be applied. Unfortunately, I'm afraid I won't make it in 3.4 M7, which is in fact the last iteration for 3.4. Thus I'm moving it to 3.5.
(In reply to comment #11) > * In comment 3 I mentioned it would be nice to have an information in the > status line about reaching the end (beginning) of the current element. I can't > find it in the patch Why such information would be useful? In case user has selected to "Do nothing" when element's end is reached the "Next difference" icon gets disabled so it's obvious that there is no next difference. I'm asking because there is an option to show additional information in the status line for the current change. This would be overridden by "End of element reached" message. One could think about displaying "End of element reached" message for a moment and then switching to the message describing the change. However I'm not sure if such approach would be consistent with the way status line works in Eclipse. I'm suggesting dropping the idea. Tomasz, what do you think?
(In reply to comment #12) > I'm suggesting dropping the idea. Tomasz, what do you think? I'm fine with dropping it.
Created attachment 128941 [details] Patch_v03 I updated the patch to HEAD and resolved some problems. First of all, with "go to next/previous element" option turned on, after reaching the last change CompareNavigator was instructed to select the first change. This led to reloading the first change on the current document. Also corrected some minor bugs with enablements of navigation buttons. Tomasz, what about a review?
(In reply to comment #14) > Tomasz, what about a review? Sure, here are my comments: * Do we need to call updateControls() for all property changes? If not, update only on events that affect buttons * Add mnemonics on the pref page * Rename "doNothingElementOption" to "doNothingOption" * I wouldn't use else block at the end of isNavigationButtonEnabled, instead I would check for an expected value. Moreover I would put an assertion there to fail if the value is not one of the constants from ICompareUIConstants. Other than the above the patch looks good, I will give it a second look as soon as the patch gets updated.
Created attachment 129064 [details] Patch_v04 Patch changed according to what Tomasz suggested in comment 15.
Released to HEAD with some minor changes, available in builds >=I20090317-1800. Thanks Pawel.
Thanks a lot!
