Back to programming

On my final push. Trying to get all basic actions working as flawlessly as possible. Dragging is being a real pain in the ass. Having to write some utility methods that I never thought I would have to write. Yeesh. Java and floating point values can be a real pain in the butt sometimes.

Today is the day

Taking a break from development to write my paper. It's going fairly well.

I hope to get back to my application in time to complete the following things:
- Have a graph and its edges completely drawable and manipulable, and undo/redoable (this part has presented a bit of an issue lately).
- Have a very basic demo plugin to simply demonstrate that the capability exists.
- Have an immaculate codebase.

While this certainly does not complete the full set of features I hope the Plotter Framework will eventually contain, I believe it's certainly a very strong starting point, and leaves a strong foundation to build on.

Whew

Half way done with the clean up. This is going to take longer than expected.

Let's Wash that Code!

Code cleaning time. I'm almost reaching the deadline, and while the program isn't yet entirely finished (and the stupid edge/vertex dragging is still bothersome), I have enough here where a code clean/refactor makes sense, and would be a wise use of time.

I'll be back up for air in a couple hours, see you then!

Undo Manager and Curved Edges

The undo manager can be a pain in the butt! The chaining/aggregation of events had me befuddled for quite a while indeed. Initially I didn't realize that I had to chain the events manually (that the UndoManager wouldn't do it for me if I told it that I wanted a chain). But then when I realized that I had to manually implement the chaining, it made more sense why that was the case. It matters whether the chained events are invoked before or after the current event on undo and redo!

Concerning curved edges, Dondi sent me this interesting SVG sample spline. I think I could incorporate that logic and make a pretty sweet edge. Fortunately I think that I've found a way to intuitively offer the CubicCurve2D as the underlying edge implementation. This way being only allow one edge to be selected for control point manipulation at a time, thus only showing one edge's control points at a time. This will leave no ambiguity as to which edge the control points are for. We'll determine whether this is a decent long-term solution. Previously I had envisioned showing the control points for all edges at the same time. That would have led to a large amount of confusion and ambiguity.

Maven

Adding project support for Maven. About time! While refactoring the project directory structure for Maven, Subclipse did not have a fun time. Commits got all screwy just to get things back in order. I did have one major commit without a comment on accident. For this I apologize! Anyhow, we now support Maven.

Ctrl-Z!

Implementing the undo/redo stack. I'm providing the standard Undo/Redo Edit menu options with the nearly ubiquitous Ctrl-Z/Ctrl-Y accelerators, respectively. This is requiring a substantial refactor, as all logic for the undone/redone actions must be abstracted. Of course this abstraction ultimately results in a much cleaner code-base, but comes at the expensive of a substantial amount of work.

Relative to the previous post, I never really did take the step back to refactor and comment. But I think I have a decent feature-set now where a substantial refactoring/commenting session might be in order.

Taking a step back

Minor setback with CubicCurve2D. It turns out that the edge doesn't pass through its control points, they're mainly guides for the cubic solver that generates the curve's equation. This means that dragging control points directly can get a little hairy. I will need to discuss this with my advisor (Dondi). I'm hoping we can figure something out such that we can keep CubicCurve2D and still have the UI remain clean and intuitive.

In the mean time I'm going to take a step back and clean up the code I have thus far and ensure all the features that I've created thus far are functioning properly. I'm also going to clean up the code as I go along.

Concerning new features, I intend on implementing undo/redo shortly.

Progress report

Just implemented hilighting of edge control points in preparation for their dragging to produce curved edges.

My itinerary hence-forth to meet the requirements of the application include:
- Complete edge/control point mouse manipulation.
- Handle and render edge crossings properly.
- Ensure the grid, including edges and crossing configurations, are being saved properly.
- Enhance the plug-in interface and features. (the scale of this is dependent on the amount of time I'll have, but I expect to get quite a bit done on this front)

Also required:
- Code cleanup.
- Additional commenting and documentation.
- Maven support.

A bit of an aside

A product that supports AOP, like Spring, would have been quite useful for this project. For example, many of the methods in the Grid class modify the grid's state, and then dirty the grid and ask for a repaint. The modifications made to the grid's state are unique to each distinct method, but the dirtying and request for repaint could be abstracted away through AOP. Would have made for a slightly cleaner implementation.

Curves and lines

So, when plotting a 2(.5)D projected 3D embedding of an abstract graph, a critically important feature is, of course, the plotting of edges. To allow for flexibility in an embedding, it's important to allow for embeddings aside from simply straight-edge embeddings. Thus, one must be able to plot curved edges. Having implemented this feature in my prototype version of this plotter, I've gained a bit of experience in perhaps what to use and not to use to facilitate such an implementation. In the prototype I decided to roll my own logic for curved edges. I did this to allow for an unlimited number of control points through which a curve would travel, to facilitate the plotting of any curved shape one might imagine. This involved the utilization of a linear algebra/matrix package to solve polynomials of potentially nth degree, and was a big pain in the butt to implement. I promised myself I would take a cleaner approach for the "production" version of the plotter. Further, very rarely did we ever create an edge with more than 2 control points (not including the end points). Thus, a cubic curve would have worked just fine. Coincidentally, the Java standard library contains a CubicCurve2D. Hooray!! :)

Pluggable analysis

Added the basic functionality for pluggable graph analysis algorithms. The algorithms are packaged as jars with entry points that implement an Algorithm interface. The jars can be selected via the "Load Algorithm" item in the "Analyze" menu. When the algorithm is successfully loaded it is added to the "Algorithms" sub menu of the "Analyze" menu, from where it can be invoked. The code certainly needs to be expanded upon and cleaned up/refactored, and additional functionality must be added.

View menu

Just implemented functionality for the view menu. This includes zoom in/zoom out/reset zoom. Some decisions had to be made regarding accelerator keys and menu item labels. The overwhelmingly-popular zoom in and zoom out menu labels appear to be "Zoom In" and "Zoom Out". Not surprising. Thus, those are what I chose to go with. The accelerator keys, however, presented a bit of a dilemma. Personally I'm a bit partial to the Firefox (and several other popular programs) Ctrl++ and Ctrl+-, but if you notice, Ctrl+- actually suggests Ctrl+=, since - is the shifted version of the = key. Not only is this a bit disconcerting for me, as this was the first time I realized this inconsistency, but Java in its Action framework will render out Ctrl+= and not Ctrl+-, which prevented me from using it. (FYI with Ctrl+- as the accelerator, Ctrl+Shift+= == Ctrl+- doesn't work, at least in the Linux impl of Java Swing) Thus, I went with a less intuitive but more consistent Cltr+M (m for minus) for zoom out and Ctrl+P for zoom in. The controls for the reset zoom button appear pretty standard, only the label is "Reset Zoom" and not "Reset" as is commonly used, because the button in fact resets the zoom level, and not the whole of the scrollable grid view.

Additionally, some rather intricate (for me, probably because I hadn't done it before) logic had to be implemented to determine how to resize the grid inside the scrollpane on zoom.

File menu

The File menu is now fully functional it seems. There's logic to facilitate New/Open/Save/Save As/Exit. In support of this I implemented fairly standard logic to prompt a user to save his/her grid prior to program exit or change discarding in favor of a new or opened grid. I also added the file name currently being modified to the title bar in standard fashion, including a standard * (asterisk) to the immediate left of the file name to signify a dirty grid (unsaved changes).

Minor considerations

How to format the items in the File menu..

You'd think mnemonics and accelerators for the typical File menu operations of New/Open/Save/Save As would be standardized, if not across platforms, then within heavy-use applications on the same platform. Well, they're not!

I've found that New, Open and Save are fairly standard, using Ctrl+N, Ctrl+O and Ctrl+S accelerators respectively.

Save As, however, presented a minor conundrum. One of the most popular applications around - Firefox - doesn't even have a "Save As" option, and instead uses "Save Page As". Intriguing, however, is that the key mnemonic used is 'A', which is the mnemonic used for "Save As" is many other applications, but the accelerator is Ctrl+S, which is the accelerator used for "Save" in most applications.

In Eclipse, "Save As" doesn't even get an accelerator by default (yuck!).

After digging at bit further, I found that many applications intended for use on Linux use "A" as the mnemonic and "Ctrl+Shift+S" as the accelerator. I like this quite a bit, and thus have incorporated it into the Plotter.

Hello again

It's certainly been a while! Development has once again commenced on the plotter. I'd like to first clarify/augment the scope of the plotter application that I'm developing. My intent is to create a Java Swing-based application that can perform and facilitate the following tasks:
- Display a scrollable 2D grid
- Add/remove/drag vertices
- Add/remove/drag quadric-curve edges
- Save/open graphs to/from disk
- Provide a "drag-net" feature where elements caught in the mouse-dragged net will be selected
- Provide a pluggable interface for algorithm plugin jars to facilitate analysis of plotted graphs

The code is present in the following Google code repository:
http://code.google.com/p/plotterframework/

Until my next post!..