Community
Participate
Working Groups
The current version of StyledCellLabelProvider.paint(...) does not respect the current alignment of the current column. Unfortunately, this is rather difficult as a new version cannot be implemented outside the org.eclipse.jface.viewers package as vital interfaces are package local. Also the StyledCellLabelProvider.paint(...) cannot be overriden in a sub-classes as some of the needed methods are private to StyledCellLabelProvider (e.g. getViewerCell(...)).
By the way: If you fix this, then please make sure that we can optionally have a different alignment for the column header and the column data. You often want to have center alignment for all headers, and yet have left and right alignment for text and number related columns.
Hitesh is now responsible for watching bugs in the [Viewers] component area.
Created attachment 158821 [details] Potential fix v01 Here is a possible patch.
Created attachment 158822 [details] perf test The test is not very useful, but, strangely, I ended up writing a performance test for this.
Although the above patch is rather simple and I get an all UI test pass with the patch, it is likely that this must have been avoided for some reason. Adding Boris for comment.
Created attachment 158825 [details] perf test
Just came across a few more related bugs. We should defer this until Bug 292198 is fixed.The layout should be updated completely during the measure event.
Ankur and I just ran into this in PDE. When we switch from a labelprovider to a styledcelllabelprovider the alignment of the other columns was removed.
Any plans of this one making it for M7?
(In reply to comment #7) > Just came across a few more related bugs. We should defer this until Bug 292198 > is fixed.The layout should be updated completely during the measure event. If we don't have the time to optimize, we should just apply the proposed patch, and add a comment on bug 292198 so that we can move the alignment logic when we do optimize.
Fix released to HEAD.
Hitesh, I've reverted the fix in HEAD because it causes screen cheese and wrong label positioning. Test Case: 1. start new workspace using HEAD or N20100413-2000 2. Window > Open Perspective > Java Browsing 3. create a Java project 'P' 4. create a new class 'C' (in default package) ==> observer the cheese in the Packages view 5. in the Projects view select the jsse.jar ==> no cheese but labels not centered in Packages view (if you don't see it immediately, then unselect and select the jsse.jar several times) I didn't verify it but I suspect this fix might also affect performance.
Created attachment 164816 [details] modified Snippet051 Here's a modified Snippet051 I used to test this. StyledCellLabelProvider#updateLayoutAlignment(TextLayout, ViewerCell) had several problems: - cell.getTextBounds() is expensive and unnecessary, since the calling method already has the bounds (and checked for null) - layout.setWidth(..) throws an IAE when I make the columns small - when the columns are too small to show the entire text, they start wrapping. That's unwanted and causes information loss. Not even the tooltip shows the cut text any more.
(In reply to comment #12) > Hitesh, I've reverted the fix in HEAD because it causes screen cheese and wrong > label positioning. Thanks > > Test Case: > 1. start new workspace using HEAD or N20100413-2000 > 2. Window > Open Perspective > Java Browsing > 3. create a Java project 'P' > 4. create a new class 'C' (in default package) > ==> observer the cheese in the Packages view > 5. in the Projects view select the jsse.jar > ==> no cheese but labels not centered in Packages view (if you don't see it > immediately, then unselect and select the jsse.jar several times) Dani, I haven't been able to reproduce this yet. Will give it further try. > I didn't verify it but I suspect this fix might also affect performance. (In reply to comment #13) > Created an attachment (id=164816) [details] > modified Snippet051 > > Here's a modified Snippet051 I used to test this. > Thanks for catching it early, I had doubts about the performance (Comment 4). Let me investigate and respin the patch if it makes sense.
I'm not sure what you're trying to do with the MeasureItem event (bug 309785). Can't you just implement this in StyledCellLabelProvider#paint(Event, Object), using layoutBounds and textBounds to calculate x such that end of the text is aligned to the right side of the textBounds? The GC should take care of the necessary clipping (and if it doesn't, you could maybe use GC#setClipping(..) in the meantime).
Does anyone know if this bug is gonna be fix anytime soon?
(In reply to comment #16) > Does anyone know if this bug is gonna be fix anytime soon? Not sure if we'll be able to get to this soon. Help would be appreciated - see comment 15 for implementation ideas.
We used Hitesh potential fix because we needed to deliver this to our client ASAP and move to the next module. The only Con we found was that it justifies the column text and creates new lines to fit the rest of it if any.
(In reply to comment #18) > We used Hitesh potential fix because we needed to deliver this to our client > ASAP and move to the next module. The only Con we found was that it justifies > the column text and creates new lines to fit the rest of it if any. See comment 12 and comment 13 for the issues it causes.
I'm also having this problem and wait for a fix.
If you really need it, you can provide a patch along the lines of comment 15.
Do you mean I should patch the jface.jar myself? I've tried overriding StyledCellLabelProvider.paint but a lot of methods or variables are not accessible.
No, I meant you could attach a patch here that correctly implements the column alignment right in StyledCellLabelProvider.java. We don't intend to make the implementation details of that class accessible for overriding, but we would be glad to release a fix that solves the problem for everyone.
*** Bug 270729 has been marked as a duplicate of this bug. ***
Created attachment 222959 [details] Patch with fix. This patch implements the fix suggested in comment #15. It's a rather small changes so I hope it's not too simplistic. I had to set the clipping region to avoid painting over the cell's image.
Created attachment 222960 [details] Extension to the StyledCellLabelProviderTests.
Comment on attachment 222959 [details] Patch with fix. The patch works nicely *and* there is no cheese regardless of the size of the column (or during column resizing). I tested this on Mac and Windows using Dani's test case, Markus' snippet and the PDE launch config / target platform page (both of which use the StyledCellLabelProvider)
Comment on attachment 222960 [details] Extension to the StyledCellLabelProviderTests. The patch adds the ability to change the layout to confirm it is being respected. I did have to add in a call to: tableViewer.getTable().setHeaderVisible(true); so that the column header would show up.
Pushed patches to: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3b201b43045552d0e18ce87bcf22863bf44f099d Thanks Pawel.
Created attachment 275306 [details] Text Clipping Bug Demonstration I am pretty confident that the solution for this bug introduced another bug which has already been documented here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=414292. I have uploaded this attachment that can be run that demonstrates this bug. You will notice that the text in the first column is clipped a little bit and if you resize the column (make it smaller and then make it bigger) you should notice a lot of artifacting and weird behaviour. Mousing over the row after performing the above steps causes the cell to re-draw itself and the graphical glitches are fixed. I believe that this is probably due to the gc.setClipping() lines added in this commit.
(In reply to Matthew Janssen from comment #30) > Created attachment 275306 [details] > Text Clipping Bug Demonstration > > I am pretty confident that the solution for this bug introduced another bug > which has already been documented here: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=414292. I have uploaded this > attachment that can be run that demonstrates this bug. You will notice that > the text in the first column is clipped a little bit and if you resize the > column (make it smaller and then make it bigger) you should notice a lot of > artifacting and weird behaviour. Mousing over the row after performing the > above steps causes the cell to re-draw itself and the graphical glitches are > fixed. I believe that this is probably due to the gc.setClipping() lines > added in this commit. Lets deal with this in bug 414292.
