Thanks, that works for me, the tests are properly installed and distributed now.

One more small thing, after running the test, the figures and all graphical elements still exist in the user's environment. Running 'figure' after the test creates 'Figure 4'. Would it be better to write the test as something like

%!test
%! unwind_protect
%!   hf = hgload ("ofig403.ofig");
%! unwind_protect_cleanup
%!   try, close (hf); end_try_catch
%! end_unwind_protect

Thanks for tackling that, patch looks right to me, but I don't have time to test it today. If the tst and ofig files are installed with "make install", and are included in the tarball with "make check", then it's doing the right thing.

I just noticed the auxiliary files in test/figure_files that go with this test also need to be included in the build system. I think they can also safely be included in the same TEST_FILES variable, but then it's easy to lose track of which .tst file they go with.

It might be more maintainable and easier to understand if these files were all grouped together in a subdirectory, similar to other subdirectories that have associated function files, or the C source files in test/mex.

I pushed the patch here:

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

Marking this bug "ready for test"

I agree that the test cases from the patch should be added to stable.

My comment was just that the patch also makes a small change to struct2hdl - I am actually happy with it and think it is a good strategy to create the figure invisible first, populate its content and make it visible at the end if required (it might actually be faster and will prevent a figure to appear temporarily if it was meant to be invisible at the end of the day anyway). As long as the input structure to struct2hdl always defines the "Visible" property then things will behave in the same way. It would affect the following code though:

s_oct40 = [];
s_oct40.handle = 1;
s_oct40.type = "figure";
s_oct40.properties.tag = "";
s_oct40.children = [];
s_oct40.special = [];

get (struct2hdl (s_oct40), "Visible")

But it is not an issue if the input to struct2hdl is always coming from hdl2struct/hgload where all of the properties are always present.

@Mike: I think any change that may affect those functions should go to default now (we don't want to change the way we save/load figures in the middle of a major version). So this patch should go to default I think.

@gyom (response to your comment in bug #44670): yes, currently we save all the properties, regardless of their value being the default. So if the figure used to be visible, its "visible" property will be restored afterwards. This is not efficient, but ensures a figure is open in later versions with the same properties  values as before. See the example of the colormap which changed between 4.0.x and 4.2.x

I haven't had a chance to take a look at this patch or test it yet, do you think this should be on stable for 4.4?

I think it's appropriate to include data files for tests, preferably in a subdirectory of the test directory along with the associated test commands.

I don't think it's appropriate to have a visible figure appear during the test suite. That would be useful for a demo.

@gyom: yes indeed it would be very useful, but having a test_save_load.ofig binary file would even let us store larger and more complicated figures.

@Mike: Are there already such test-only data files in Octave sources?

I pushed a fix here:

http://hg.savannah.gnu.org/hgweb/octave/rev/64c6e8bfc9e5

Closing report

If I try to open a figure generated with octave 4.2 with the current stable I see the following error:

hgload /tmp/toto.ofig
warning: 'drawmode' is deprecated and will be removed from a future version of Octave
error: addproperty: a 'interpreter' property already exists in the graphics object
error: called from
    struct2hdl>addmissingprops at line 657 column 7
    struct2hdl>createline at line 294 column 3
    struct2hdl at line 144 column 7
    struct2hdl at line 167 column 13
    hgload at line 58 column 5

This is in my opinion a very nasty bug that must be fixed before Octave 4.4.