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!..

Shift

Okay, so, my focus has changed from the 3D visualizer, to a 2D plotter.

I currently have a prototype version of the plotter, but it needs to be redone. Dr. Mellor and his Topologist colleagues hope to have the application by this summer so they can continue their work. It's currently not in a state where anyone but myself can use it as its usability is so inconsistent.

Thus, my over-arching objectives are:
- Recreate the plotter such that it's highly usable. In other words, it should comply with the usability features of popular drawing/diagramming applications.
- Have the source clean enough where 1) it can be open-sourced, and 2) Dr. Mellor and his colleagues (who know a bit about programming) can maintain it.
- Provide a pluggable algorithm functionality for running algorithms against the embeddings.

As part of the motivation for writing the plotter from scratch, I did a bit of searching around for programs that have similar functionality. Searching through Google, and looking over http://www.computop.org/, there's really nothing close in functionality to what TopPlot will provide. The closest applications I found (which are not really close at all) are:
- KnotPlot - purely 3D visualization application. Among other deficits, it doesn't provide for 2(.5)D projections, nd doesn't have an algorithm interface.
- Knotilus - A knot/link generator, without any plotting or direct manipulation.

Mathematica has a GraphPlot[] function, but it doesn't support direct manipulation of the produced graph, it doesn't provide information about edge crossings, and it only supports straight-edge embeddings.

There are also, of course, paint programs, but those are purely visual. We desire an underlying representation of the vertices and edges plotted such that algorithms can be run against them.

I've done some initial scenario and use-case analysis on paper in my TopPlot. I shall show it to Dondi!

Also, I'm going to be using the Shag-GUI library to provide functionality on top of basic Java Swing (such as an undo stack). I've started to read the API documentation.

Further, I've created the following Google Code project for TopPlot: http://code.google.com/p/topplot/

Java Web Start

Things have recently transpired in my life which have made it fairly difficult to make progress on my school work.

I did manage to configure TopPlot as a Java Web Start on the LMU Keck web servers. It was relatively painless actually.

Over the next few days I intend on making significant progress towards getting vertices plotted.

JOGL Up and Running

Just completed the beginner's JOGL tutorial located here: http://www.land-of-kain.de/docs/jogl/. The tutorial was fairly recent but used JOGL 1.x. Several of the API calls in Java 2.x are slightly different but I was able to make my way around without much difficulty. The tutorial demo is available in my CVS repository under the TopPlot3D module, class edu.lmu.cs.lorenabrams.jogldemo.JoglDemo.

For the tutorial I hardwired my platform's (AMD64 Linux) .jar and .so files into my execution environment. My next step, however, will be to cross-platformify this process using Java Webstart, so everyone (or nearly everyone) will be able to launch the application without having to manually install the JOGL/OpenGL libraries and configure their runtime environments.

From the looks of things, the JOGL API's closeness to the C OpenGL API is as advertised, which will be much appreciated during TopPlot's development! Further, and much to my delight, it appears that JOGL provides some pretty neat utilities on top of standard OpenGL, including texture loading/mapping helper classes, and a frame-rate moderator.

Unfortunately my OpenGL is extremely rusty, so the ramp-up to full speed development might be rather lengthy, but I hope to be there within the next week or two.

Until next time!
Loren

To SIGGRAPH or not to SIGGRAPH

Tomorrow is the deadline for SIGGRAPH 2010, and unfortunately they require an image to be submitted along with the application. This may prevent us from submitting to the conference. I'm going to attempt to contact someone at SIGGRAPH shortly regarding tentatively submitting without an image. Hope that works out!

Anyway, Dondi and I have decided that I should attempt to implement the following 3 features:

• Vertex occlusion detection/correction
• Edge crossing accentuation
• 2D projection production (optional, for the time being)
  

Given such, I've coined the following 50-words-or-less pitch for TopPlot (for SIGGRAPH):

We developed a visualization system for realizing and manipulating spatial embeddings of topological graphs. The visualization system provides features such as vertex occlusion correction, edge-crossing accentuation, and 2D projection formation to aid mathematicians in topological graph analysis.

Concerning development, by this time weekend I intend having TopPlot's JOGL skeleton up and running.

Thanks!
Loren

Initiate Project.. Check!

TopPlot (as it's tentatively named) will be a spatial graph embedding plotter, and it will consist of 2 primary components.

The first component will be a 2D grid backed by functionality facilitating the plotting of vertices and edges on the grid. This component will further require the user to specify which edge should be on top at each edge crossing in order to specify a spatial embedding for the graph. With the requisite elements of the graph's spatial embedding specified, the grid will in all intents and purposes represent the embedding's XY projection.

The second component of TopPlot will take as input a graph embdding's XY projection as specified using the first component and realize it in 3 dimensions. The full set of capabilities for this component are yet to be finalized (and will most likely be somewhat fluid as the project progresses throughout the semester) but some initial features identified as being useful to the end user are:

• Functionality to navigate (fly) through the graph's spatial embedding.
• Functionality to facilitate direct manipulation of edges and vertices.
• Functionality for the visualizer to somehow compensate for important embedding elements that may be hidden, such as hidden vertices, or hidden edge crossings.

Much of TopPlot's first component has already been developed as a prototype while working with Dr. Mellor in Loyola Marymount's Math department. The prototype's code is, however, quite messy, and given that TopPlot's code will be handed over to others (probably Dr. Mellor) for maintenance and potentially further development following this semester (and may in fact be open sourced) I've elected to rewrite a good portion of the prototype code.

This past weekend I began rewriting it. To those who have access to my CVS repository in the Keck lab (I'm talking to you Dondi), the source is located in the TopPlot module.

Much more detail will be included in my next post...

Loren