Expandable SWT/JFace Dialog

This confounded me for a while, so here's the short:

1. Extend JFace Dialog
2. Keep a handle to the content of your expandable section
3. Do this (from ErrorDialog):

private void toggleDetailsArea() {
Point windowSize = getShell().getSize();
Point oldSize = getShell().computeSize(SWT.DEFAULT, SWT.DEFAULT);
if (listCreated) {
list.dispose();
listCreated = false;
detailsButton.setText(IDialogConstants.SHOW_DETAILS_LABEL);
} else {
list = createDropDownList((Composite) getContents());
detailsButton.setText(IDialogConstants.HIDE_DETAILS_LABEL);
}
Point newSize = getShell().computeSize(SWT.DEFAULT, SWT.DEFAULT);
getShell()
.setSize(
new Point(windowSize.x, windowSize.y
+ (newSize.y - oldSize.y)));
}


Working with Checkboxes in TreeItems

I spent some time working out how to get my Tree checkboxes functional. I'm reusing the SpellsView across the display and edit view (with AbstractSpellsView:

public void createPartControl(Composite parent) {
...
if (isEditable()) {
// select checkbox
TreeColumn treeColumn11 = new TreeColumn(tree, SWT.NONE);
treeColumn11.setWidth(60);
}
TreeColumn nameCol = new TreeColumn(tree, SWT.NONE);
nameCol.setWidth(60);
nameCol.setText("Name");



The subclasses override the getInput(), the abstract view includes a switch in the create and LabelProviders to update or ignore the checkbox.

One Perspective to Rule Them All

I've had a few discussion about the "failings" of the Eclipse perspective model to effectively deal with the complexity of information management within an IDE. While most of his arguments are perfectly loony, he made the point that Eclipse imposes a "Debug Perspective" on you while coding, causing the developer to lose focus as you switch from whatever his main work perspective is. This bugged me enough in the past to create a new window to house the Debug perspective. The new solution:

Porting to RCP

After taking the charmgr as far as I could with PyGTK, I've decided to port it over to the Eclipse RCP. Whatever its failings, I love the frameworks and architecture, and expertise in Eclipse is marketable. The philosophy is about 180 degrees from Python (I've read many posts lauding Python's lack of rigid frameworks), but being from Java, the RCP is my comfort zone.

Porting the UI was trivial using the Visual Editor (though not nearly as simple as Glade):


I used Derby as a replacement for SQLite, and after populating the Spell tree using straight SQL, I thought I'd look into Hibernate for data access. The Hibernate framework hides the SQL from the code, provides a lot of connection management functionality, and has the added benefit of generating most of the boilerplate DAO code. Unfortunately I ran into an access problem when trying to initialize Hibernate from the RCP:

 private Object getInput() {
  logger.debug("getInput()");

  HibernateUtil.currentSession();

Basically get a ClassNotFoundException on Session. This solved by creating a plugin from the jar and registering it in the MANIFEST.MF.

After flopping around for a bit, I violated good practice and copied the hibernate.cfg.xml file to the root of the org.hibernate plugin. This solved the problem for the short term. I then moved all the dependent jars to their rightful place in the hibernate plugin and as well the creating an org.apache.logging plugin for those libs (so both hibernate and charmgr can access the logging). I cheated again by copying the log4j.xml to the logging plugin to resolve that little classpath issue.

So my current workspace looks like this:



and the main view is now functional: