Jig plugin: First Look

Here's where the Jig plugin stands so far:
1. The plugin will be split into components instead of one big interface.

2. There are three interfaces that I see so far. A tool interface(for new tools), a Menu interface(for adding new menus to the menu bar), and a MenuItem interface(for adding menuitems to already constructed menus).

3. The Menu interface will have a single method:
public JMenu getJMenu();

4. The MenuItem interface will have a single method as well:
public Map getJMenuItems();
The Map will be mapping JMenuItems with AvailableMenus. AvailableMenus are the available menus that a JMenuItem can be attached to.

5. The Tool interface is the next thing to be considered.

to be continued...

Plugins

The Drawable class has been successfully changed and the undo/redo functionality is in place. The next step is to create an interface for Jig plugins.

Before I work on creating the interface, I'm going to layout the use case for each plugin that I'll be developing. These Plugins are:
1. POAP plugin
2. M.O.S.A.I.C. plugin (this is a plugin based n my senior project)
3. POAP/M.O.S.A.I.C. plugin

The idea is to somewhat create the plugin interface from what I need instead of creating a plugin interface and trying to fit my needs into that package.

Also, I'll add the design changes that Donsi and I talked about which he also wrote comments about.

Refactoring

I was able to talk with Dondi about how I could fix the problems I was having with the Drawable objects in Jig. Dondi suggested removing transient data from drawable objects and make a distinction from magnets and vertices.

All Drawable objects had to implement a method called haveIBeenClicked(Point p), which would return true if if the drawable had been clicked(or hovered over) and false otherwise. The problem though is that the mouse cursor can click different parts of the Drawable to cause different effects. For example, if a user clicks on a single vertex, then the user can simply move that vertex, but if the user is clicking on the Drawable as a whole, then moving would cause the whole Drawable to move. Those different functionalities can't be abstracted out of a single method. So it was decided to create a utilities class with static methods to determine what part of the Drawable had been hit.

The other change is to separate vertices from magnets. Currently there is a magnet object that tries to be both, the only problem is that vertices and magnets are different things. So Drawables will now contain Magnets and Vertices.

I'll post some javadocs on the changed classes later.

Hitting a brick wall

I've been working adding undo/redo functionality to Jig and I've just encountered a slight hinderence. Each tool that Jig has uses a Controller class to manage the mouse events. To add undo/redo, these Controller classes simply tell the Commander object to execute a desired Command class. For example, the polygon tool uses the PolygonController class for creating new JPolygons. The PolygonController class adds the polygon to the canvas once the user has released the mouse button. To add undo/redo, I created a class called AddPolygonCommand which implements the Command interface within the shag library. The PolygonController class then simply tells the commnder object to execute a new instance of this command.

Simple enough, but while writing the MovePolygonCommand, which would be used by the PointerController when a user uses the pointer tool to move a polygon, I discovered that the PointerController doesn't differenciate when the user clicks on a polygon to move it, and when a user clicks on a vertex of a polygon to move only the vertex, not the whole polygon itself. That functionality is in the JPolygon class. This poses a problem because that functionality needs to be abstracted out of the JPolygon class so that the PointerController can undo/redo the different movement commands correctly.

I'll update on the progress towards fixing this problem.

Shag

Spent today getting together a game plan for integrating undo/redo capabilities into Jig. At first I thought the code would need quite a bit of refactoring to get this task accomplished. After looking at some sample code, I found that David had done a pretty nice job of separating the right pieces of code. So instead of rewritting code, I can spend the rest of the week implementing.

I've also spent some time researching the Java SPI model, and I have a better understanding of how I can use that to create plugable components for Jig. I'm still unsure what components of Jig are going to be plugable, but I'll get to that soon enough.

First Post

Here's my first post, it's a little late, so lets get started with the details.

This blog details my progress through my CMSI 499 Gesture Recognition class at Loyola Marymount. The class is focusd on learning through:
1. Reading published papers on the subject
2. Using and enhancing on gesture recognition code created by David Hoffman
3. Incorporating that code into a gesture based drawing program called Jig

Here's where I'm at so far:

I am successfully a part of the jig and poap projects. I have CVS access to jig via the LMU computer lab and I have access to poap via SourceForge.net.

Current goals:
1. Look at how to incorporate undo/redo into jig.
2. Make small test program that utilizes Java SPI.
3. Continue reading articles about gesture recognition.

That's what's going on this week. I'll keep you posted.