Community
Participate
Working Groups
Created attachment 286634 [details] screenshot Egit recently introduced an additional modifier state display for merge conflicts. This has the side effect of breaking horizontal scrolling and consuming some of the available space for nothing (since the place needed for modifiers is consumed even when no modifiers are shown). With long file names this is really a problem. In the example screenshot I cannot see which apache commons libs I'm dealing with (and I already enlarged the column from its default size on my rather small laptop display).
How about: 1. We move that column to the front. 2. We hide that column if there are no conflicts.
+1
Would that also fix the horizontal scrolling? I consider this missing the bigger of the two problems. If I can scroll, then the wasted space is not that important.
Not sure this will work. Running into crazy problems with this. Just swapping the columns (and adapting some code to deal with the fact that then column 0 is the indicator, and column 1 the real content) in any case doesn't cut it. The second column needs to have some width, and it appears to break the tree layouts. Either I'm doing something wrong, or something is broken in trees with multiple columns. If the latter, some other much more elaborate way would need to be found. Maybe something like a ruler (line numbers); basically a separate widget scrolling in sync with the tree and showing that indicator. Could then remain on the right. Then the tree itself still only has one column and should have horizontal scrolling. Yes, I understand that the lack of scrolling is a problem.
This is tough. I don't see a way to have tree with more than one column, with the last column being sized as if there was no column at all specified. That zero-column case, in which SWT internally manages some native column, is very special... A separate widget tied to the scrolling (and expansion state) of the tree would be a lot of work for little benefit. Other alternatives: 1. Simply put the indicator into the label, for instance as a "M >" prefix. Doesn't look as nice, and we'd lose the hover showing the slightly fuller explanation, unless we can choose which hover to show based on mouse coordinates. (Tricky in a RTL layout?) 2. Custom draw the rows. That's not going to be easy either; we might have to account for horizontal scroll offsets, and overpaint on the right with the indicator. Unsure how and where the indicator should be drawn in a RTL layout. This might also need additional changes to the hover ("normal" StagingViewTooltip and the hover on the indicator) to display one or the other depending on mouse coordinates. Don't know what custom painting would do to performance when there are many items, but hopefully the framework would invoke the painter only for the actually visible rows.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/182394
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/182394 This is an attempt to fix this via custom drawing the conflict type indicator. Looks OK in my tests on all three platforms; one minor glitch on Windows using the Neon target platform in my tests: on a selected item, the selection color is a light blue, but the indicator is drawn with a dark blue background. Might be an SWT bug, perhaps fixed since Neon. RTL layout not handled.
(In reply to Thomas Wolf from comment #7) > one minor glitch on Windows > using the Neon target platform in my tests: on a selected item, the > selection color is a light blue, but the indicator is drawn with a dark blue > background. Might be an SWT bug, perhaps fixed since Neon. Doesn't seem to be fixed. I've filed bug 574434 for this.
Another minor glitch concerning the background color of the owner-drawn rectangle on GTK3 in dark mode is bug 574484. Occurs in 2021-06, but not in a child Eclipse (Neon.3, egit-4.6 target platform). On GTK3 in Neon.3, the redrawing when changing the width of the unstaged viewer is very laggy, but that appears to have been fixed; works well in 2021-06. On Mac the colors are correct in both light and dark mode.
However: on Mac (OS X 10.14.6) with Eclipse 2021-06, tree items are apparently not repainted on (horizontal or vertical) scrolling. Horizontal scrolling also scrolls the indicator, which then appears right in the middle of the label instead of at the right edge. :-(
(In reply to Thomas Wolf from comment #10) > However: on Mac (OS X 10.14.6) with Eclipse 2021-06, tree items are > apparently not repainted on (horizontal or vertical) scrolling. Horizontal > scrolling also scrolls the indicator, which then appears right in the middle > of the label instead of at the right edge. :-( Seems to be a new bug in Eclipse 2021-06. Works fine in Eclipse 2021-03. Not reproducible with a stand-alone SWT tree snippet. Perhaps in JFace?
(In reply to Thomas Wolf from comment #11) > (In reply to Thomas Wolf from comment #10) > > However: on Mac (OS X 10.14.6) with Eclipse 2021-06, tree items are > > apparently not repainted on (horizontal or vertical) scrolling. Horizontal > > scrolling also scrolls the indicator, which then appears right in the middle > > of the label instead of at the right edge. :-( > > Seems to be a new bug in Eclipse 2021-06. Works fine in Eclipse 2021-03. > > Not reproducible with a stand-alone SWT tree snippet. Perhaps in JFace? Cannot reproduce stand-alone, only with a real Eclipse downloaded from [1] with EGit installed from the locally built update site. But [2] is a work-around. [1] https://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/2021-06/R/eclipse-java-2021-06-R-macosx-cocoa-x86_64.dmg [2] https://git.eclipse.org/r/c/egit/egit/+/182394/4..5/org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/staging/StagingView.java
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/182394 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=38b94d2c25678ea83669a8753ff9e01b6083acc8
