OK. I'll go look at the patches in that bugfix. I will also need to get an Ubuntu VM up and running to work on that. For some reason the uicontrols aren't working on my OSX install.

But, I guess some of my original questions still stand:
1) Should we try to regularize the handle names in Octave to match those of Matlab. It may end up being that the Octave handles are a strict subset.
2) Should we make our struct2hdl and hdl2struct result in FIG files that can be interchanged between Matlab and Octave. This would probably be the only way that a GUI developed by a Matlab user (fig-file plus m-file) could be used as-is by and Octave user.

As there have been various discussions on the maintainers mailing list about a method support a GUI builder, it made me start thinking about how I like the fact that the Matlab GUIDE only requires a FIG file and an associated M file as the underlying file format. Some people were in favor of the QTCreator ui files, which I am fine if that is the decision, but decided to try and get FIG files generated by Matlab to load in Octave.

I found a great website called undocumentedmatlab.com that explains that FIG files are just a MAT file that contains the figure information (see http://undocumentedmatlab.com/blog/fig-files-format). I think someone within Octave must have already known this because the hdl2struct and struct2hdl functions already are almost identical in underlying structure to the structure contained within a FIG file.

However, for the life of me I couldn't get struct2hdl to work for me in trying to load a Matlab-generated FIG file to load. There seemed to be a couple problems:
1) too many places where Octave's struct2hdl would fail if the FIG file struct didn't have properties named exactly the same as Octave was expecting.
2) struct2hdl wasn't handling the reading of the title, xlabel, ylabel, zlabel correctly. In the FIG struct, they are listed as children, but in the resulting axes handle these text handles need to be assigned to the corresponding property in the axes handle, rather than just added as children. It seems that Matlab does not add them as children, but does assign the handle to the appropriate axes property. It seems that Octave both adds them as children and assigns the handle to the appropriate axes property. The mapping for these non-regular children is handled with the "special" field of the axes sub-struct.

So, I wrote a fairly simple script that seems to be loading simple FIG files generated from Matlab into Octave. It recursively depth-first traverses the FIG struct, creates an object based on the handle type (not all are supported yet), and assigns any properties from the FIG struct that exist in the Octave handle. In the case where some of the children are irregular, the special field of the struct is used to determine the mapping from children to properties.

Is suspect the the Octave struct2hdl and hdl2struct are self-consistent, it is just that they don't handle the conversion from Matlab FIG struct to an Octave handle. I think the right approach is to try to fix up the existing struct2hdl and hdl2struct to be compatible with the FIG struct from Matlab, but am wondering if that will break a bunch of other people's code or existing figures that have been saved as structs in MAT files.

Thoughts?