the new Faces of JFace (part 1)


Some of you may have noticed JFace provides new API to streamline JFace usage and to support new features like:

  • custom owner draw
  • tooltips for tree/table-cells
  • keyboard editing support for viewers

To provide all those new features we (Tod Creasey, Boris Bokowski and me) decide to refactor the underling JFace code, provide new classes and to move things from specialized classes to more generice ones. The central of the whole refactoring brought up a whole bunch of new classes where the most important are the following:

  • ColumnViewer: Provides all things common to Viewers who deal with the concept of columns and rows
  • ViewerRow: Represents a row in the column viewer and wraps TableItem and TreeItem from SWT
  • ViewerCell: Represents one cell in the table/tree

We decide to create those new classe because it gives us the possibility to push as much code in the widget independent ColumnViewer instead of the widget centric classes derived from it.

All the changes mentionned above might not be interesting to you because most of the time you want use them directly so let’s take a look at the more interesting things from a user point of view.

The most interesting thing to most of you might be that JFace has now adopted the programming style from SWT and JFace-Coding feels now much more like SWT-Coding. Look at the next few lines and you understand what I mean:

Composite parent = ...;
TableViewer v = new TableViewer(parent);
v.getTable().setLinesVisible(true);

TableViewerColumn vColumn = new TableViewerColumn(v,SWT.NONE);
vColumn.getColumn().setWidth(200);
vColumn.setLabelProvider(new MyLabelProvider());

v.setContentProvider(new MyContentProvider());
v.setInput(model);
Advertisements
This entry was posted in 3.x. Bookmark the permalink.

8 Responses to the new Faces of JFace (part 1)

  1. Bull says:

    I have been studying the idea of providers and model based viewers for things other than Tables / trees / lists, (extending JFace for Info Vis), and I used the concept of a Style provider. I wonder if this would make sense to set styles such as LinesVisible, showHeaders, etc…

  2. Benno says:

    I have two questions:
    1. Given a ColumnViewer is it possible to get the i-th ViewerColumn?
    (In M3: ColumnViewer#getViewerColumn(int) but is now package visible)
    2. Given a ViewerColumn is it possible to get its LabelProvider?
    (In M3: ViewerColumn#getLabelProvider() but is now package visible)

    What I want is given a TableViewer get its i-th CellLabelProvider.

    Thanks

  3. Tom says:

    The question is why you need to get access to those 2 internal methods. If you can provide a use case please log a request in bugzilla.

    We made them package visible because we couldn’t think of a use case where one needs to get access to them.

    The reason to make ColumnViewer#getViewerColumn(int) package visible was that the result when calling is not the same all the time:
    – ViewerColumn for Tables/Trees with no column
    – TableViewerColumn/TreeViewerColumn for Table/Trees with one and more columns

    The reason to make getLabelProvider() package visible was that we couldn’t think of a use case someone want to access it from external. But as said provide a usecase and we can think about it.

  4. Tom says:

    StyleProvider seems interesting but I’d prefer having style constants for those features:
    – SWT.TITLE => to shown title
    – SWT.SEPARATOR => to show lines

    Please log a feature request against platform-ui and prefix it with [Viewers] and put me on the cc-list.

  5. Benno says:

    https://bugs.eclipse.org/bugs/show_bug.cgi?id=167858

    I have the same use case as you have in ToolTipSupport: I want to show a custom tool tip and set its content with the text retrieved from CellLableProvider#getToolTipText.

  6. Phil says:

    I have a question regarding complete owner draw of columns. I want one column to draw itself in a SWT.DrawItem manner. Is this still possible with the new ColumnLabelProvider mechanism in place?

  7. Tomek says:

    Hi,
    I want to create my own viewer based on ColumnViewer and I have a problem with implementation of StructuredViewer#doUpdateItem method. AbstractTableViewer uses ColumnViewer#getViewerColumn(int) method, but I can’t. I think, I found a solution, but I need to create a new instance of ViewerCell. And the next problem is, the constructor of ViewerCell class is package visible, too. Can I find somethere a right implementation of this method?

  8. Tom says:

    Well if you don’t have a column based viewer (= I get this from your comment that ColumnViewer#getColumn doesn’t work) then you might subclass the class above. You could always file a bug and ask us to open the ViewerCell-API.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s