From the top, but this time with feeling

A character manager for a smartphone actually makes sense, so I'm writing it over again in Javascript. By the time I finish I may actually own one of these phones. What finally sent me over the edge was TaffyDB, a "database" for the browser. I can store all the data in these hashes, and Taffy gives you a nice way way to pull the data you're interested in. I think of the databases as Excel sheets (or Calc sheets, for the FOSS folks), and there are goodly number of Excel-based character managers out there, so I should be able to pull this off.

This is the end (for now)

The thing is done. The database is fairly stable, the edit perspective is basically done, and most importantly, I'll never use it.

Todos:

• Feat special rules need to be implemented


• MainPerspective calculated values (melee, damage, etc.)


• Create charactersheet print out

CheckboxTableViewer.setChecked() fails silently

Took me a while to figure this out:

If you have a CheckboxTableViewer and want to set the initial state of the table contents as (un)checked, you cannot do the initialization in the LabelProvider. It seemed like the most logical place, and the viewer does enter the code for setChecked(element, true), but nothing is displayed. Turns you have to let the table draw first (I don't understand why):

public void update() {
// inputs the same
tableViewer.setInput("");
tableViewer.refresh();

List weapons = WeaponHome.inst.findAll();
for (DAO weapon : weapons) {
if (Ctx.getChar().weapons.contains(weapon)) {
((CheckboxTableViewer) tableViewer).setChecked(weapon, true);
}
}
}

For the record, this is the code that does not work:

public String getColumnText(Object element, int columnIndex) {
String value = "";
Weapon weapon = (Weapon) element;
if (isEditable()) {
if (Ctx.getChar().weapons.contains(weapon)) {
((CheckboxTableViewer) tableViewer).setChecked(element, true);
}
}

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: