Ah, yes.  It works quite nicely.  I checked the patch in under your credentials here (https://hg.savannah.gnu.org/hgweb/octave/rev/301186dbef68).

@Guillaume: Is there test code that I can use to verify your patch in comment #36?  It seems to me that the s_oct40.children.handle field is already assigned.

@Rik: Maybe we can restrict the scope of this report to implementing all base graphics objects.

The "special" field not being implemented correctly prevents us from handling axes labels. So I would say lets keep this report open until axes (and the special field) and uicontextmenus are fully functional.


As of today though, Octave can't open any Matlab figure file that contains graphics created with high level functions (even basic "plot")... but we could file another bug report about that.

So far, I've been concerned with compatibility with Matlab figures (e.g. from a hgS_070000 struct) so the fix is in struct2hdl.m. From what I understand from Pantxo's comment #3 and comment #6, hdl2struct.m uses a different behavior for the "special" field (storing indices instead of handles):
https://hg.savannah.gnu.org/hgweb/octave/file/a21d7d269472/scripts/plot/util/hdl2struct.m#l75
https://hg.savannah.gnu.org/hgweb/octave/file/a21d7d269472/scripts/plot/util/struct2hdl.m#l618
so if a change was made to use Matlab mechanism, there would be a backward compatibility issue with figures saved by Octave (in a s_oct40 struct).

I fixed the semicolon issue here: https://hg.savannah.gnu.org/hgweb/octave/rev/8e0475e6ec15.

Many thanks Rik, it works!

There is a semi colon missing here:
https://hg.savannah.gnu.org/hgweb/octave/rev/a21d7d269472#l1.116

One issue I observe concerns a uicontextmenu that does not get attached to its parent uicontrol. It relates to this:
https://hg.savannah.gnu.org/hgweb/octave/rev/a21d7d269472#l1.133
and I guess it touches upon Pantxo's comment #3 about the "special" field. From what I understand, in Matlab, the "special" field from a uicontextmenu contains the handle of the uicontrol it's the child of.

Otherwise I think we can close this bug report and open a fresh new one to discuss Pantxo's larger changes to hdl2struct/struct2hdl.

I applied the fix_open.patch here https://hg.savannah.gnu.org/hgweb/octave/rev/4f502f56664e.

I additionally modified it so that it checks for the .ofig extension whether an output is requested before deciding to call openfig.

-  elseif (any (strcmpi (ext, {".fig", ".ofig"})))
-    output = openfig (file);
-    drawnow ();
+  elseif (any (strcmpi (ext, ".ofig")))
+    if (nargout > 0)
+      output = openfig (file);
+    else
+      openfig (file);
+    endif

I reviewed the fix_open.patch.  Why is this line deleted from open.m?

-  elseif (any (strcmpi (ext, {".fig", ".ofig"})))
+  elseif (strcmpi (ext, ".ofig"))

Don't we want openfig to be called if the ".fig" extension is present?

I made a few changes pushed the changeset here:

http://hg.savannah.gnu.org/hgweb/octave/rev/c9ae077dedd1

Please take a look at this and let me know if I did the right thing with open.m.

I also pushed the new savefig function from bug #53403.

@pantxo: yes, sure, it makes sense. I had forgotten about that other bug report. openfig also has a commented out call to movegui, now implemented in bug #53400.

@gyom: I'll be happy to help integrate your patches and make our figure loading/saving mechanism more robust and eventually ML compatible. Give me some time to take a look at this in the coming week.

Adding this comment as a reminder that when hdl2struct/struct2hdl will have been upgraded to handle uicontrols, the following change will have to be made in copyobj.m:

diff -r affd44707573 scripts/plot/util/copyobj.m
--- a/scripts/plot/util/copyobj.m       Thu Apr 19 19:16:54 2018 -0700
+++ b/scripts/plot/util/copyobj.m       Fri Apr 20 14:46:12 2018 +0100
@@ -41,7 +41,7 @@
 function hnew = copyobj (horig, hparent = 0)

   partypes = {"root", "figure", "axes", "hggroup"};
-  othertypes = {"line", "patch", "surface", "image", "text"};
+  othertypes = {"line", "patch", "surface", "image", "text", "uicontrol"};
   alltypes = [partypes othertypes];

As it stands, the patch from comment #13  that includes changes in openfig.m, hgload.m and open.m is in my eye ready to be applied to the default branch.

I attach a patch implementing openfig.m as a wrapper around a slightly modified version of hgload.m (to support a second input, as in Matlab). It also includes changes to open.m.

Remaining changes for better support of Matlab figures will have to take place in struct2hdl.m; I started working on that following comments #6 and #7.

(file #43558)

An ?original? version of the file seems to be here, w/o a license:

https://github.com/carangorango/color-categorization-games/blob/master/OCTread_FIG.m

I think we cannot accept files w/o a license.

I just wanted to bring my portion of the discussion over from a duplicate bug I had created. That commentary is available in the linked "duplicate" bug, but I am reposting here to keep it in the same discussion.

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 using the current Octave hdl2struct.

(file #38031, file #38032)

Thanks Pantxo, I just tried struct2hdl on a .fig file and it did work quite well. I have a few remarks:

• figure: properties do not seem to be taken into account (Position, Name, MenuBar, ...).
• uicontrol: if an element does not have a style property, the default is "pushbutton" (see below).
• uicontrol: for compatibility, a uicontrol frame could be changed into a uipanel (see below).
• uicontrol: each element is first displayed with default position (bottom left of the figure) then moved to its final location, which is slow.

Here are the small changes I made to the createui() subfunction:

function [h, s] = createui (s, par)
  if (isfield (s.properties, "style") && strcmp (s.properties.style, "frame"))
    s.type = "uipanel";
  endif
  switch s.type
    case "uicontrol"
      if (!isfield (s.properties, "style"))
        s.properties.style = "pushbutton";
      endif
      h = uicontrol (par, "style", s.properties.style);
      s.properties = rmfield (s.properties, "style");
      if (isfield (s.properties, "cdata") && isempty (s.properties.cdata))
        s.properties = rmfield (s.properties, "cdata");
      endif
    case "uipanel"
      h = uipanel (par);
    case "uibuttongroup"
      h = uibuttongroup (par);
    otherwise
      eval (sprintf ("h = %s (\"parent\", par);", s.type));
  endswitch
  addmissingprops (h, s.properties);
endfunction

Hi Pantxo, do you have any updates on the hgload() front? I've been happily using my implementation of openfig() for a while now but it would be good to rely on your code. You mentioned that you already had a preliminary cset available - would you be able to find and share it?

We don't want to duplicate efforts and that's why we implemented a structure similar (same fields) to Matlab one in the hope that struct2hdl would be able to handle both Octave and Matlab figures. Unfortunately I misinterpreted the "special" field and the current version is not compatible with Matlab figures.

I think I am the one who proposed the .ofig extension, maybe to avoid bug reports from users trying to open Matlab figs while we know we are not able to render them properly. You are right that the name of the variable in the structure is enough to know where the figure comes from and we should not restrict the extension (as we do with "run" function).

Would you agree if I retitle this bug report "hgload can't open Matlab figures" then we see what can be done/merged from your implementation of openfig?

Hi,

Can you explain the difference between "openfig" function and "hgload". The latter is already implemented for use with Octave figure structures. It is currently not "allowed" to open Matlab .fig files as there are differences in the way the "special" field is handled in Octave and Matlab, but I have a preliminary cset somewhere in my computer that brings Octave in line with Matlab in this regard.
Also legend/colorbars and any object that has listeners on other parts of the figure won't work properly (this is also true for pure Octave figures).