Page 1 of 2

Tree mode directory comparison issues

Posted: Mon Feb 19, 2024 12:30 am
by Alexo
The new tree mode directory comparison has several issues:

1) Mouse wheel scrolling does not respect user settings.

I have set up the mouse wheel to scroll one page on every click:

Capture.JPG
Capture.JPG (16.2 KiB) Viewed 2769 times

It works perfectly in the "flat" mode.
But in the tree mode, it scrolls one line at the time, and in the opposite direction.

2) Column widths in tree mode are not preserved when switching to flat mode and back.

3) Expand to difference does not work well.

Some folders with differences remain unexpanded.

Please fix.

Re: Tree mode directory comparison issues

Posted: Mon Feb 19, 2024 2:47 pm
by psguru
Thanks for your comments.
1) Mouse wheel scrolling does not respect user settings.
Is your focus on the top diff combo box? If so, EDP will scroll diffs, not tree views, and it will do so one line at a time. When a new diff is selected in the diff combo, it is expanded in the tree, and this may sometimes look like the controls scroll backwards.

Scrolling tree view does respect the setting you mentioned.
2) Column widths in tree mode are not preserved when switching to flat mode and back.
This will be fixed in the next build.
3) Expand to difference does not work well.
Some folders with differences remain unexpanded.
Please provide a screenshot with more details.

Re: Tree mode directory comparison issues

Posted: Mon Feb 19, 2024 6:45 pm
by Alexo
This clip shows two of the issues:
  1. New folders are not automatically expanded.
  2. Flat comparison scrolls by screenfulls while tree comparison scrolls by one line at a time (and in the opposite direction).
(Why can't I attach an MP4???)

Re: Tree mode directory comparison issues

Posted: Tue Feb 20, 2024 1:18 am
by MSpagni
Alexo wrote: Mon Feb 19, 2024 12:30 am 3) Expand to difference does not work well.
Some folders with differences remain unexpanded.
Sounds familiar... :wink:

Re: Tree mode directory comparison issues

Posted: Tue Feb 20, 2024 9:40 am
by psguru
New folders are not automatically expanded.
This behavior is controlled by the option below. I think you want to select the second setting in the dropdown.

expand-to-diffs-options.png
expand-to-diffs-options.png (70.59 KiB) Viewed 2736 times

Flat comparison scrolls by screenfulls while tree comparison scrolls by one line at a time (and in the opposite direction).
I can't reproduce this. Moreover, the mouse wheel scrolling code has something like this to determine the number of rows to scroll by:

Code: Select all

::SystemParametersInfo(SPI_GETWHEELSCROLLLINES, 0, &nScrollLines, 0);
(Why can't I attach an MP4???)
You can now.

Re: Tree mode directory comparison issues

Posted: Fri Feb 23, 2024 7:28 pm
by Alexo
psguru wrote: Tue Feb 20, 2024 9:40 am This behavior is controlled by the option below. I think you want to select the second setting in the dropdown.
That's it! Thanks!

psguru wrote: Tue Feb 20, 2024 9:40 am
Flat comparison scrolls by screenfulls while tree comparison scrolls by one line at a time (and in the opposite direction).
I can't reproduce this. Moreover, the mouse wheel scrolling code has something like this to determine the number of rows to scroll by:

Code: Select all

::SystemParametersInfo(SPI_GETWHEELSCROLLLINES, 0, &nScrollLines, 0);
I think that's the issue.

A full screen scroll is indicated by the value (-1).
If the code is naive, it will scroll one line in the opposite (negative) direction, instead of one screenful in the correct direction.

Re: Tree mode directory comparison issues

Posted: Fri Feb 23, 2024 7:38 pm
by Alexo
I searched a bit, and it seems that Microsoft themselves had a similar bug in the terminal :D

https://github.com/microsoft/terminal/i ... -622458242
Two bugs. We're storing the return value from SPI_GETWHEELSCROLLLINES as an int when it should be a uint, and we're ignoring WHEEL_PAGESCROLL (which once we store it in the wrong type comes out as -1).
Here are the instructions: (emphasis mine)
The variable "pulScrollLines" points to an unsigned integer value that receives the suggested number of lines to scroll when the mouse wheel is rotated without modifier keys:
  • If this number is 0, no scrolling should occur.
  • If this number is WHEEL_PAGESCROLL, a wheel roll should be interpreted as clicking once in the page down or page up regions of the scroll bar.
  • If the number of lines to scroll is greater than the number of lines viewable, the scroll operation should also be interpreted as a page down or page up operation.
The default value for the number of scroll lines will be 3. If a user changes the number of scroll lines, by using the Mouse Properties sheet in Control Panel, the operating system broadcasts a WM_SETTINGCHANGE message to all top-level windows with SPI_SETWHEELSCROLLLINES specified.
Cheers,
Alex

Re: Tree mode directory comparison issues

Posted: Sat Feb 24, 2024 12:23 pm
by psguru
The code that uses SPI_GETWHEELSCROLLLINES directly is in the GUI library we use for the tree control. We can change the calculation to the one we use for other mouse wheel scrolling, such as in the text control. Which leads to a question: does wheel scrolling work for you there?

Re: Tree mode directory comparison issues

Posted: Sat Feb 24, 2024 3:04 pm
by Alexo
As I showed in the clip above, wheel scrolling works correctly in the flat mode - every wheel "click" scrolls one page in the correct direction, as configured in the mouse settings. Similarly, the file comparison also treats scrolling correctly, only the tree mode has this problem.

Which one is the "text control"?

Re: Tree mode directory comparison issues

Posted: Sat Feb 24, 2024 3:27 pm
by psguru
Text control is used in file comparison and merge. OK, we'll switch to using another way of calculating scroll lines. The change will appear in the next build. The new build ( 15.0.0.8 ) is available now.

Re: Tree mode directory comparison issues

Posted: Sat Feb 24, 2024 4:22 pm
by Alexo
File comparison scrolling works as expected.

Re: Tree mode directory comparison issues

Posted: Sat Feb 24, 2024 4:23 pm
by psguru
What about tree scrolling in the new build?

Re: Tree mode directory comparison issues

Posted: Sun Feb 25, 2024 8:13 pm
by Alexo
psguru wrote: Sat Feb 24, 2024 4:23 pm What about tree scrolling in the new build?
It requires me to restart the computer after the update, I will do it when possible.
Before the restart, scrolling is still incorrect.

One more thing that misbehaves:
I expect the column sizes and sorting order to be saved for both tree mode and flat mode, and restored when switching between them.

Re: Tree mode directory comparison issues

Posted: Mon Feb 26, 2024 10:06 am
by psguru
I expect the column sizes and sorting order to be saved for both tree mode and flat mode, and restored when switching between them.
We currently share this configuration between comparison modes. Isn't it more convenient?

Re: Tree mode directory comparison issues

Posted: Mon Feb 26, 2024 8:36 pm
by Alexo
psguru wrote: Mon Feb 26, 2024 10:06 am We currently share this configuration between comparison modes. Isn't it more convenient?
It absolutely isn't. See attached examples.

To summarize:
  • In tree mode, the "name" column is shifted right by the subdirectory depth, so it needs to be wider than in tree mode to display the same information.
  • In flat mode, I display an additional "relative path" column, and shrink the other columns to make space the way I like.
  • I sort by "relative path" in flat mode. Switching to tree mode and back loses the sort setting.
In short, you shouln't have the same column widths when one mode has 4 columns and the other mode has 5.
And you can't sort by the same column when one of the modes does not have it.

Also, I like the fact that the header is a different colour in tree mode. Is it possible to do it in flat mode as well?

Aside:
Attachment size limits are too small!
256KB is not enough for a screenshot at a decent quality (I had to compress mine to hell), and definitely not enough for a clip.

tree.jpg
tree.jpg (241.15 KiB) Viewed 2663 times
flat.jpg
flat.jpg (250.34 KiB) Viewed 2663 times