Try to compare a file with many differences. Most of the time when we launch the diff screen, status shows the last diff as the current diff position though the highlighting is on the first; Eg: in my case it showed 4/4 but the cursor was at the first difference. And clicking on the RHS marker line to navigate to the difference works as expected but it does not update the status; Eg: I clicked on the third diff marker line and it navigated to the third diff but the status did not change to 3/4.
Please provide an example with a screenshot.
I have attached screenshots with descriptions.
Btw, I launched diff window as follows
1) Right click a modified file in a mounted directory with Git VCS configuration.
2) Choose Version Control -> Compare with Base Version.
I have attached screenshots with descriptions.
Btw, I launched diff window as follows
1) Right click a modified file in a mounted directory with Git VCS configuration.
2) Choose Version Control -> Compare with Base Version.
I'm still looking at these 2 issues noted here:
I'm still looking at these 2 issues noted here:
Thanks for the details on the stripe. It did not strike me that the error stripe indicates caret position and it is different from the diff selection indicated by thick black borders.
Thanks for the details on the stripe. It did not strike me that the error stripe indicates caret position and it is different from the diff selection indicated by thick black borders.
#2 was an off-by-one error, which I have patched. It only happens when you have 9 lines (and 99, etc), ie at the border between n and n+1 digits. Being so minor, not sure if it's worth making a whole Vincaed build for it.
#1 seems to be a racing condition.
You have the EventQueue thread creating the diff UI, validating and such and the RefreshDiffTask thread which computes the diff asynchronously. (And you also have a 3rd thread common.ui.BackgroundThread which sets the location to 0 much to early).
The diff window also has a feature called 'smart scrolling' which changes the selected difference automatically while you scroll.
So, we have two situations:
* if RefreshDiffTask finishes *after* the UI is displayed, the 1st difference is selected by default (which is correct)
* if the RefreshDiffTask finished *before* the UI is displayed, it saves the differences list and afterwards, during UI revalidation the selected difference index is re-computed according to 'smart scrolling' and another difference index is picked based on the view and the visible differences.
What you should do in this situation is perhaps listen on the diff view events (EditableDiffView will fire an DiffController.PROP_DIFFERENCES event when RefreshDiffTask executed) and call EditableDiffView.setCurrentDifference(0) only then.
BUG #4: Please note that when smart scrolling kicks in (on scroll and even on window resize) the toolbar 'View next/previous difference' buttons get out of sync.
For example if 4/8 gets selected by scrolling and the buttons believe I'm on 1/8, pressing the 'previous' button does nothing while pressing the 'next' button takes me to 2/8 and not 5/8 as expected. You should use EditableDiffView.getCurrentDifference to see if the index didn't change in the mean time via smart scrolling.
#2 was an off-by-one error, which I have patched. It only happens when you have 9 lines (and 99, etc), ie at the border between n and n+1 digits. Being so minor, not sure if it's worth making a whole Vincaed build for it.
#1 seems to be a racing condition.
You have the EventQueue thread creating the diff UI, validating and such and the RefreshDiffTask thread which computes the diff asynchronously. (And you also have a 3rd thread common.ui.BackgroundThread which sets the location to 0 much to early).
The diff window also has a feature called 'smart scrolling' which changes the selected difference automatically while you scroll.
So, we have two situations:
* if RefreshDiffTask finishes *after* the UI is displayed, the 1st difference is selected by default (which is correct)
* if the RefreshDiffTask finished *before* the UI is displayed, it saves the differences list and afterwards, during UI revalidation the selected difference index is re-computed according to 'smart scrolling' and another difference index is picked based on the view and the visible differences.
What you should do in this situation is perhaps listen on the diff view events (EditableDiffView will fire an DiffController.PROP_DIFFERENCES event when RefreshDiffTask executed) and call EditableDiffView.setCurrentDifference(0) only then.
BUG #4: Please note that when smart scrolling kicks in (on scroll and even on window resize) the toolbar 'View next/previous difference' buttons get out of sync.
For example if 4/8 gets selected by scrolling and the buttons believe I'm on 1/8, pressing the 'previous' button does nothing while pressing the 'next' button takes me to 2/8 and not 5/8 as expected. You should use EditableDiffView.getCurrentDifference to see if the index didn't change in the mean time via smart scrolling.
The racing condition is also a NetBeans bug which I've reported upstream as #227145. But if you want it fixed for ADS you could work around it with that listener on EditableDiffView as I've mentioned.
#4 is also ADS-related so from my part this bug is resolved.
Please change the dev if somebody else will continue working on the ADS-side.
The racing condition is also a NetBeans bug which I've reported upstream as #227145. But if you want it fixed for ADS you could work around it with that listener on EditableDiffView as I've mentioned.
#4 is also ADS-related so from my part this bug is resolved.
Please change the dev if somebody else will continue working on the ADS-side.
Vincaed 3.0.5.6 includes the fix for
> 2. Line number cut off.
Vincaed 3.0.5.6 includes the fix for
> 2. Line number cut off.
>1. The diff window doesn't always start with the same difference selection.
I've backported the upstream fix for #227145 to Vincaed. It will be part of a future build (it's too small right now to warrant a release).
>1. The diff window doesn't always start with the same difference selection.
I've backported the upstream fix for #227145 to Vincaed. It will be part of a future build (it's too small right now to warrant a release).
There are differences in how the text compare functions in v14.0.0-beta-75 and v13.0.3-13. In both of these versions, what Asif reported has not been completely fixed.
In v14.0.0-beta-75 the bottom-most change is highlighted by default ( the dark gray spline bolding ) once the comparison is run.
Clicking on another change in the right side navigation sidebar does not shift the dark gray spline bolding and does not change the numbers indicated at the top of the center column. You can see a light yellow highlight in only the right side text editor.
In v13.0.3-13 the top-most change is highlighted by default ( the dark gray spline bolding ) once the comparison is run.
Clicking on another change in the right side navigation sidebar does not shift the dark gray spline bolding and does not change the numbers indicated at the top of the center column. You can see a light yellow highlight in only the right side text editor.
The only way to successfully see changes in the spline highlighting AND the numbers indicated at the top of the center column is to use the "Next Change" and "Previous Change" buttons in the top right corner of the compare pane.
I am attaching gif Animations showing the behavior of each version.
There are differences in how the text compare functions in v14.0.0-beta-75 and v13.0.3-13. In both of these versions, what Asif reported has not been completely fixed.
In v14.0.0-beta-75 the bottom-most change is highlighted by default ( the dark gray spline bolding ) once the comparison is run.
Clicking on another change in the right side navigation sidebar does not shift the dark gray spline bolding and does not change the numbers indicated at the top of the center column. You can see a light yellow highlight in only the right side text editor.
In v13.0.3-13 the top-most change is highlighted by default ( the dark gray spline bolding ) once the comparison is run.
Clicking on another change in the right side navigation sidebar does not shift the dark gray spline bolding and does not change the numbers indicated at the top of the center column. You can see a light yellow highlight in only the right side text editor.
The only way to successfully see changes in the spline highlighting AND the numbers indicated at the top of the center column is to use the "Next Change" and "Previous Change" buttons in the top right corner of the compare pane.
I am attaching gif Animations showing the behavior of each version.
Please take a look at the v14 behavior & let me know if there are any issues with it that need to be fixed.
Please take a look at the v14 behavior & let me know if there are any issues with it that need to be fixed.
Issue #8050 |
Closed |
Fixed |
Resolved |
Completion |
No due date |
Fixed Build 31812 |
No time estimate |
Please provide an example with a screenshot.