Community
Participate
Working Groups
Created attachment 283826 [details] Selection Background makes commit messages invisible Hi all, I'm facing this problem with EGit 5.8.0.202006091008-r installed to Eclipse Integration build I20200808-1800. In the "History" view, I cannot see any commit messages of those commits I select in the table. This is the same for both Light theme, Dark and Classic.
Cannot reproduce. Might be a platform problem. Which OS X version?
Ah, sorry. Forgot to mention that. MacOS11 Beta 4.
In that case it's probably a platform problem. Moving to Platform/SWT.
The problem still exists with the latest integration build of Eclipse (13th Sep) on MacOS Big sur.
Created attachment 284284 [details] Eclipse I20200925-1800; macOS 11.0 Beta (20A5374i); Git integration 5.10.0.202009212321 The text-hiding effect doesn't seem to appear on any of the tables/trees of the Eclipse platform (see attachment). This is on: - Eclipse I20200925-1800 - macOS 11.0 Beta (20A5374i) - Git integration 5.10.0.202009212321
Same on macOS 11.0 Beta (20A5395g)
Same on Big Sur 11.0.1 beta (20B5012d) But this is only on the Git table, so is this SWT? And I can see white text in the "Committed Date" column. Is there something in the Git table label provider that is not respecting the system table color or font?
I didn't check the implementation yet - but with the commit graph displayed in oneof the table's columns, this is probably not just plain SWT used by a JFace StructuredViewer API. That's why I created the issue in the EGit integration project - in the hope that someone from the EGit-UI-developer-team could help. What I can say is that I see the described effect solely on the Git history table. I'm now working on macOS11-only for a week, and all other tables are just fine.
(In reply to Ingo Mohr from comment #8) > I didn't check the implementation yet - but with the commit graph displayed > in oneof the table's columns, this is probably not just plain SWT used by a > JFace StructuredViewer API. > > That's why I created the issue in the EGit integration project - in the hope > that someone from the EGit-UI-developer-team could help. > > What I can say is that I see the described effect solely on the Git history > table. I'm now working on macOS11-only for a week, and all other tables are > just fine. Yes, that table does some special rendering to plot the commit graph. My feeling is that this is an EGit_UI issue.
It doesn't occur on OS X 10. Therefore I suspect that something is different on OS X 11 that causes problems in JFace or SWT with such a table. The only special thing I can think of is that the column showing the graph and the commit messages is owner drawn. All other columns are normal. If it were a problem in EGit's owner draw code I'd expect it to affect only that one column and none of the others. I don't have OS X 11, so I can't dig into this myself.
Created attachment 284617 [details] Table with check boxes (In reply to Thomas Wolf from comment #10) > It doesn't occur on OS X 10. Therefore I suspect that something is different > on OS X 11 that causes problems in JFace or SWT with such a table. The only > special thing I can think of is that the column showing the graph and the > commit messages is owner drawn. All other columns are normal. If it were a > problem in EGit's owner draw code I'd expect it to affect only that one > column and none of the others. > > I don't have OS X 11, so I can't dig into this myself. Yes, owner drawn columns exhibit this behaviour. It happens also if a checkbox is used in a table. See attached screenshot.
I'm also able to see this in Eclipse Quick search dialog and with Snippet 231.
I confirm that, macOS 11.0.1 (20B29)
*** Bug 568827 has been marked as a duplicate of this bug. ***
(In reply to Thomas Wolf from comment #10) > It doesn't occur on OS X 10. Therefore I suspect that something is different > on OS X 11 that causes problems in JFace or SWT with such a table. The only > special thing I can think of is that the column showing the graph and the > commit messages is owner drawn. All other columns are normal. If it were a > problem in EGit's owner draw code I'd expect it to affect only that one > column and none of the others. > > I don't have OS X 11, so I can't dig into this myself. I upgraded to MacOS 11.0.1 last weekend and now also suffer from this. Do you have any hints where to dig ?
(In reply to Matthias Sohn from comment #15) > Do you have any hints where to dig ? If I wanted to debug this, I think I'd start with a breakpoint in Table.drawInteriorWithFrame_inView() and check the rectangles. It feels as if the background for the owner drawn cell is drawn across the whole row. But maybe Lakshmi can give a better idea of where to start.
I see additional issues : Hover over a variable when stepping statements during debugging. This opens the debug hover card but that doesn't show the variable and its current value but is empty. When stepping over a method call with an active breakpoint inside this method the editor jumps to the method with the breakpoint and the lines above the breakpoint are not refreshed. The Java editor still shows the code from the previously shown method above the breakpoint where the debugger stopped.
(In reply to Matthias Sohn from comment #17) > I see additional issues : > > Hover over a variable when stepping statements during debugging. This opens > the debug hover card but that doesn't show the variable and its current > value but is empty. That's bug 567787. > When stepping over a method call with an active breakpoint inside this > method the editor jumps to the method with the breakpoint and the lines > above the breakpoint are not refreshed. The Java editor still shows the code > from the previously shown method above the breakpoint where the debugger > stopped. Might be new, perhaps related to bug 567615. The tracking bug for OS X 11 problems is bug 565691.
This bug here seems to be caused by the SWT.EraseItem listener? See bug 568905.
(In reply to Thomas Wolf from comment #19) > This bug here seems to be caused by the SWT.EraseItem listener? See bug > 568905. Yes, the Bug happens only when there is a SWT.EraseItem listener. For example try Snippet 231. In Table/Tree, we don't draw the highlight in highlightSelectionInClipRect() if there is a EraseItem listener (see if (hooks (SWT.EraseItem)) return;) In drawInteriorWithFrame_inView(), when selection has to be drawn, we call callSuper (widget.id, OS.sel_highlightSelectionInClipRect_, cellRect); This draws the selection properly on older versions, but on BigSur, looks like this draws the selection over the text and checkbox. Interestingly, only the last column is not affected by this problem, the selection in the last column seems to be drawn correctly in the background. Any help or ideas to fix this are welcome.
*** Bug 568905 has been marked as a duplicate of this bug. ***
(In reply to Lakshmi P Shanmugam from comment #20) > callSuper (widget.id, OS.sel_highlightSelectionInClipRect_, cellRect); Is the cellRect correct at that point? Or does it encompass the whole row? If this call draws the selection over the whole row, it's clear that only the last column drawn will look correct.
(In reply to Thomas Wolf from comment #22) > (In reply to Lakshmi P Shanmugam from comment #20) > > callSuper (widget.id, OS.sel_highlightSelectionInClipRect_, cellRect); > > Is the cellRect correct at that point? Or does it encompass the whole row? > If this call draws the selection over the whole row, it's clear that only > the last column drawn will look correct. cellRect looks correct there, it doesn't include the whole row.
(In reply to Lakshmi P Shanmugam from comment #23) > (In reply to Thomas Wolf from comment #22) > > (In reply to Lakshmi P Shanmugam from comment #20) > > > callSuper (widget.id, OS.sel_highlightSelectionInClipRect_, cellRect); > > > > Is the cellRect correct at that point? Or does it encompass the whole row? > > If this call draws the selection over the whole row, it's clear that only > > the last column drawn will look correct. > > cellRect looks correct there, it doesn't include the whole row. Thanks Thomas for the pointer. Though the cellRect is correct and doesn't include the whole row, the full row is being drawn for every cell. In the patch, we draw the background ourselves in this case.
@Sravan, this issue looks bad on BigSur. It would be good if we can push this change for M3 so that it gets some testing.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/172438 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0c32ec3c65077edeca694b38cca5df6f209454b4
Tested with I20201118-1800. Few more issues remain when EraseItem is hooked 1. Full selection is not drawn for the whole row 2. Selection not drawn in checkbox column 3. In eclipse, the non-focus table/tree selection color looks different. I believe https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/172487 addresses issues 1 & 2.
(In reply to Lakshmi P Shanmugam from comment #27) > I believe https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/172487 > addresses issues 1 & 2. Perhaps, but that work-around is getting big and not so nice anymore. Can't we really figure out what's causing this? Does setting NSTableView.style to fullWidth explicitly help?
(In reply to Thomas Wolf from comment #28) > (In reply to Lakshmi P Shanmugam from comment #27) > > I believe https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/172487 > > addresses issues 1 & 2. > > Perhaps, but that work-around is getting big and not so nice anymore. I agree, see comments in gerrit. > Can't we really figure out what's causing this? It looks like a Cocoa bug here, since the direct call to highlightSelectionInClipRect is drawing the full row instead of the just the clipRect. > Does setting NSTableView.style to fullWidth explicitly help? Mac Table/Tree are always FULL_SELECTION, so full selection has to be drawn. Setting to any of the styles, doesn't help. Will investigate further for RC1.
> It looks like a Cocoa bug here I've had luck in the past reporting bugs through Apple's developer bug report system, by providing code sample and/or patches. Is that something doable here? Would love to help but know nothing about Cocoa so it's a steep curve for this bug :)
I opened a Bug with Apple for this issue - FB8909897 (BigSur: NSTableView.highlightSelectionInClipRect: draws highlight for whole row instead of only clipRect)
(In reply to Lakshmi P Shanmugam from comment #27) > Tested with I20201118-1800. > > Few more issues remain when EraseItem is hooked > 1. Full selection is not drawn for the whole row > 2. Selection not drawn in checkbox column I tested Table with EraseItem on macOS 10.15 today saw the same behavior there. When EraseItem is hooked, Full selection is not drawn and selection is not drawn for the checkbox column. Also, found a old for this - Bug 312735. Since this (1 & 2) are not a BigSur issues, it has to fixed on all macOS versions for consistency and will be tracked by Bug 312735. > 3. In eclipse, the non-focus table/tree selection color looks different. This is seen in Eclipse Dark mode and is caused by the fix, will address it in this bug.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/172839
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/172839 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=43ae20877473e4e4653fd23d69d34aa7464f19a6
> > 3. In eclipse, the non-focus table/tree selection color looks different. > This is seen in Eclipse Dark mode and is caused by the fix, will address it > in this bug. This is seen only in Eclipse, looks like the color is being initialised too early and the color for light theme is being used. Resolving bug. Opened Bug 569224 to track this.
Verified with M3 build.
(In reply to Lakshmi P Shanmugam from comment #31) > I opened a Bug with Apple for this issue - > FB8909897 (BigSur: NSTableView.highlightSelectionInClipRect: draws highlight > for whole row instead of only clipRect) The bug has been fixed by Apple in 11.3 Beta! I guess we can remove the workaround for 4.20.
