What's it all about, Alfie?

I came in today to see a problem in one of my apps that uses the plist parsing in CKit for preferences - much like the old Mac OS X plist files. I did this because I really liked them, and they afforded me a great deal of flexibility in the setting of the parameters for this application. But there was a problem. I hadn't found it because up to this point I edited the file and then reloaded the file into the app. But if the app wrote out the file and then tried to reload it, there was a problem.

The problem today was that I looked at the plist file and it had clearly been changed. Yet they probably hadn't changed it. What probably happened was that the app itself had written it out and then failed to read it back in properly. There was another interesting complication in the works that lead me to believe that it was the writing part and that was a feature I had put into the code from the beginning.

If I had a section of the plist that looked like this:

    backup = {
        interval_mins = 5;
        filename = "../logs/<hostname>/backup.dat";
    }

then the same could would write out:

    backup = {
        filename = ../logs/<hostname>/backup.dat; interval_mins = 5;
    }

and there's a good reason for it. First, the quotation marks are gone because it's obviously a string and there's nothing that needs escaping in the string. Secondly, for maps with less than three elements, I decided to place them all on a line so that things like points and lines are more easily visualized. What happened then was the bug.

The bug was in the reading of the converted plist. Specifically, it wasn't looking at the semi-colon as the terminator for the value on the first key/value pair. In fact, it was only looking at the line-endings as terminations and that was meaning that the filename had the semi-colon as well as the second key/value pair. That's not going to work.

The solution was simple - recognize that the semi-colon was the terminator and everything worked perfectly. Simple fix, but finding it took longer than I expected.

The guys working on MacVim have released Snapshot 40 with an impressive list of updates:

• Fix problems with Quickstart "leaking" Vim processes
• 'imdisable' now on by default (i.e. IM is disabled by default)
• Clipboard support in non-GUI mode (Kent Sibilev)
• New document icons, more filetype associations (Nico Weber)
• Add support for 'guitabtooltip' (hint: add the line "set gtl=%t gtt=%F" to your .gvimrc to make tabs display the name of the file and have the tooltip display the full path) (Jonathon Mah)
• Look for toolbar icons in runtime path (plugins such as TVO now display toolbar icons properly)
• Show dialog when clicking to close tab with modified buffers
• Update documentation
• Latest Vim source code and runtime files

Still the best cross-platform editor I've ever used.

I put a few finishing touches on the multi-scatter graph today. It was pretty much done, but I wanted to give it the ability to read the initial selections for the x-axis column as well as any y-axis columns from the applet PARAM tags. With that, the developers that asked for this can pretty much put together everything they need.

The new applet PARAM tags are pretty simple:

• defaultXAxis - this is the name of the column that is the initial selection for the x-axis.
• defaultYAxis - this is the encoded string of a Vector of Strings that are the column names to be placed on the y-axis initially.

where the encoded string is the output of the call:

  Vector    v = new Vector();
  ...
  String    str = BKTable.generateCodeFromValues(v);

where the Vector v is populated with the names of the columns to place on the graph.

I have to say it looks good and works well. I've handed it off to the developers that want to use it and supplied them with an example HTML file where it's used.

This morning I noticed that the Mozilla Group had released two releases: Firefox 3.0.4 and Camino 1.6.6. The Firefox release was about the typical security and stability fixes, and the Camino was the same. However, I have to say that this release of Camino has markedly better button rendering when going to sites that didn't render buttons nicely in the past. For that, I'm grateful.

So, it's update time for browsers. Not bad.

Well, I heard in this article that in JDK/JRE 1.6.0_12 and beyond, Sun is going to be delivering a 64-bit Java plugin. Finally. I've been waiting for a long time for this, and while I have to say it's not going to impact me that much as I don't do a lot of web/applet-based development any more, it's nice to know it's there should I ever get back to it.

Now all we need to see is a pre-packaged Firefox for Linux that's 64-bit.

This morning I noticed that Perian 1.1.3 is out and available within Perian for update. With this release they have put in a few more decoders added more sanity checks for some of the streams, and even reduced the memory footprint.

This is just a great way to be able to view a lot more diverse content in QuickTime. GOtta love that.

A few days ago (late last week) a couple of developers stopped by my cube to ask me if the BKit graphs had anything like a multi-select scatter graph where the data points were grouped into data sets and then they could be overlaid on top of one another to build up a more complex graph.

Well... the answer was clearly "No", and they didn't think so, but we got to thinking about how you could do it with the existing tools, and I got to thinking how to do it with the TwoDimCrossScatterViewer. So, I started work on the new graph as they started working on the different data structures to make it work with the existing scatter graph and the pseudo z-axis capabilities.

The first thing I knew I needed was to get the TwoDimCrossScatterViewer working without the lines. That was simple enough. But then it was on to the coloring of the data points and labels. This was a very tricky thing.

The breakthrough was finding the Status producer in the docs. The default way of associating a Status object with the data is row-dominant - meaning that a complete row has a single Status object for rendering. I needed to change that to column-based, and this little code did exactly what I needed:

    /**
     * We need to create (and use) a StatusProducer that looks at
     * the columns of the graph for a Status. If we didn't do this,
     * we'd be looking at a row at a time and that's not what
     * we're after.
     */
    AbstractStatusProducer statusProd = new DimensionalStatusProducer(DataSet.diCol);
    _graph.getData().setStatusProducer(statusProd);

with this, I could then set the Status flags for a column. Well, that's good, but all the code I have in place now assumed it's row-based. Well... time for a significant expansion of the code to allow for the testing of the kind of graph we're working with and then to switch to either "by row" or "by column" way of looking at things.

With all that, we have a pretty decent first-cut at the multi-scatter graph:

There are still things I need to do tomorrow - like a lot of testing to make sure that my changes haven't messed up another graph. But I think I'm pretty close to what the guys were looking for.

This afternoon a couple of developers stopped by trying to do something in the graphs I've built on VantagePoint, and I'll admit - it wasn't going to be easy. Basically, they wanted a multi-variable scatter graph - just like the TwoDimCrossScatterViewer, but with all the GUI widgets to make it easy to use by the target audience.

The first step was to be able to easily control the visibility of the lines on the x-y graph, because if I could do that, then I could easily build on that and just use it in the "no lines" mode and be ready to go. But in order to do that, I needed to have a clean way to turn on and off the lines in all pairs, and a pair at a time.

What I came up with was the simple applet PARAM tag showxylines. If that guy is true, then the graph will show the lines, if it's false, then it won't. If it's missing, then they will be shown, by default. The neat addition to that was to add the PARAM tag showxylines:columnName and if that's true, the lines with that column in their definition will be shown, and not otherwise. This makes it very easy to turn all lines off and then some select few on, or vice versa.

This doesn't mean I'm done, but it's a great stepping-stone. From here, I need to add in the GUI widgets to control the graph, make sure the lines are "off", and then put it all together. Not trivial, but I've done this several times and it's not as hard as all that.

The BKBaseGraphApplet can read the data it uses to put on the graphs from the applet PARAM tags a row at a time... or a complete table... or even as a part of the supportData table. This guy was meant for data that didn't make sense to put into the main data table, but was needed to support the proper graphing of the data.

Think colors of scatter points... mouse-over labels... that kind of stuff. More "style data" and not as much "numeric data". But today I realized that the parsing of the supportData and the augmenting of it to the primary data was not working properly.

I had made changes to allow the parsing of a complete table of data, in addition to the row-at-a-time method. But when I did that, I didn't follow-through with all the implications. For instance, the way the code was originally written, it was possible to leave out the primary data table completely, and then pull in parts of the supportData table as the "plotting" (aka primary) data.

In fact, it was possible to augment that as well. Very flexible, and nice, but by putting in the table parsing of the primary source, I broke it. (Well, to be brutally honest, another developer had a crack at it and I just cleaned up what he had written) So... I needed to go back in and clean it all up. Restore all the functionality I had intended to put in there.

The first step was to realize that the easiest way to resolve this was not to have the semi-merge code in the applet... Nope, that's a waste. I have the BKTable's merge() method, all I really needed to do was to put a filter on the supportData table - letting through only the columns the user wanted to merge into the primary data table, and then do the merge(). It was far simpler, and removed a ton of code from the BKBaseGraphApplet's class that was strikingly similar to the BKTable's code, and it was implemented better in the table's class.

Then I had to make sure that all different possibilities worked. No table, some table, etc. This way I could be sure that it was going to work.

In the end, it worked like a charm. The mouse-over is coming from the supportData table, and it's merging in the data exactly as it should. Perfect.

This morning I was reading the JavaDocs for VantagePoint's TwoDimCrossScatterViewer to see if I was missing anything on the secondary Y axis issue I was having yesterday, and I saw it. In working with the new graph type we have two ways of looking at the data - as pairs and as columns. In the first cut I assumed they wanted the pair number. There, in the docs, was the key I'd been missing. In the docs for the TwoDimCrossScatterViewer was the method:

    public void setSecondary(int colNum, boolean isOnSecondary)

Clear as day... they are saying that in order to put a column on a secondary axis, you have to specify the column. Not the pair. You can put either the X or Y on the primary or secondary axes - making this far more configurable than I had planned. This was very clever of Gordon. Love it.

The result is beauty:

I fired off an email to Gordon to tell him I "got it", and to ask him which question of mine he wanted to answer next. There were three:

• How to format Dates on Time Series Graphs - this is so we can make better line graphs for the developers doing a lot of time-series data.
• How to put Labels on the bars in Bar Graphs - this is in order to make the data identified in the graph and not by the legend.
• How to put Bars in a TimeSeries Graph - another developer wanted to have bars and not lines on the time series - another graph I'd have to add support for.