[Octave-bug-tracker] [bug #48586] Implementation of the openfig function

[John Swensen]

URL:
  <http://savannah.gnu.org/bugs/?48586>

                 Summary: Implementation of the openfig function
                 Project: GNU Octave
            Submitted by: jpswensen
            Submitted on: Thu 21 Jul 2016 02:47:15 PM EDT
                Category: Plotting
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Matlab Compatibility
                  Status: None
             Assigned to: None
         Originator Name: John Swensen
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.0.3
        Operating System: Any

    _______________________________________________________

Details:

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?



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 21 Jul 2016 02:47:15 PM EDT  Name: openfig.m  Size: 2kB   By:
jpswensen

<http://savannah.gnu.org/bugs/download.php?file_id=37979>
-------------------------------------------------------
Date: Thu 21 Jul 2016 02:47:15 PM EDT  Name: SineWave.fig  Size: 35kB   By:
jpswensen

<http://savannah.gnu.org/bugs/download.php?file_id=37980>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48586>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/