Community
Participate
Working Groups
As reported by Ross Camara AbstractTreeViewer would work for nebula if we would open the API a bit. Boris and I decided that we will do this in 2 steps: 1. open the API 2. moving the Virtual-Support bits from TreeViewer to AbstractTreeViewer when the nebula grid provides virtual support.
Created attachment 55569 [details] A patch to start discussion I know Boris and I have thought about opening AbstractTreeViewer but after playing around a bit i think the better idea is to take the same approach like we did for TableViewer, so I started and finally it was not really a lot of work. The only thing discussable is the name of the new Viewer called VirtualAbstractTreeViewer, I think we should come up with an equal name for both of our widget-independent-columnbased-viewers.
Created attachment 56189 [details] Open AbstractTreeViewer as much as need for subclassers Ok guys this time a patch which opens AbstractTreeViewer and moves common things from TreeViewer to it so that subclassers can easily implement a viewer on top of it. I've also included a potential implementation for Grid and a test snippet which is copied from our snippets collection. Please report back as soon as possible whether the API provided using this patch is open enough to all of you.
One comment i had when implementing the GridViewers is that in both implementations i needed to override the getViewerRowFromItem(Widget) method. The problem here is that if we don't find the viewer row in the data map of the widget we return null throwing an NPE. In the TreeViewer you override the method also so that when no ViewerRow is found we create a new ViewerRow to return. I think we should just make this method abstract and not provide the base implementation.
(In reply to comment #3) > One comment i had when implementing the GridViewers is that in both > implementations i needed to override the getViewerRowFromItem(Widget) method. > The problem here is that if we don't find the viewer row in the data map of the > widget we return null throwing an NPE. In the TreeViewer you override the > method also so that when no ViewerRow is found we create a new ViewerRow to > return. I think we should just make this method abstract and not provide the > base implementation. > well this is not possible because if we declare this method abstract in AbstractTreeViewer we would break API contracts backwards. We can declare it abstract of course in ColumnViewer and AbstractTableViewer we can do that and it would certainly make sense IMHO. That's why I once proposed to insert a new Sub-Class below AbstractTreeViewer which declares the method as abstract which could not be declared abstract in AbstractTreeViewer because of backwards compatility. E.g. getItemAt() is also such a method!
Created attachment 56880 [details] Reapply able to head
Slighlty modified patch released >20070117. Chris, can you please have a look at HEAD to make sure I didn't break your subclasses? I made two methods final that were previously not. For 3.3, we don't have enough time to address the SWT.VIRTUAL case, this will have to wait and should be tracked with a new bug.
Verified with the latest version of cvs and our viewers still work.
Tom, Boris - thanks for all the hard work.
