How to convert a GUI *.m file generated by GUIDE's export tool back to a *.fig file?

As described : https://blogs.mathworks.com/community/2011/04/04/guide-guis-in-all-one-file/, it's possible to export a GUI *.fig file (and it's *.m file) to a single *.m file, which is very useful for version controlling a project (fig files are compiled).

However, the generated single *.m file is not easy to edit again if you need to do more changes to the GUI. Is there a way to convert that file back to the *.fig and *.m files, or import that single *.m into GUIDE, so that it can be editable there?

[Pranav Kakkar]

i lost my .fig file in matlab but have its .m file. how to extract .fig out of it

[Mathieu Boudreau]

I don't think that's possible. The .m file only contains the function definitions and implementations related to your GUI, not the information that format/define the GUI objects.

[Rik]

It is indeed impossible to reconstruct the fig file from the code only (unless you have used the export functionality).

This entire thread shows why using GUIDE is a bad idea in most circumstances. GUIDE has been stuck in the same state for years (a decade?) now. For anything more complex than throwing together a GUI with 4 elements I would highly suggest using native Matlab (sometimes called a 'programmatic GUI') or AppDesigner.

Answer 1

[OCDER]

NEW ANSWER:

How about this?

1) Export your guide .fig file as a single m file. EX: myGUI.m
2) >> h1 = myGUI
3) >> saveas(h1, 'myGUI.fig', 'fig')
4) >> guide('myGUI.fig')

OLD ANSWER

You could use App Designer instead of GUI, which packages the code and figure into a single .mlapp file https://www.mathworks.com/help/matlab/creating_guis/create-a-simple-app-or-gui-using-app-designer.html

If stuck in GUIDE, I would just keep both the .fig file (to easily edit the "View") and the .m file (to easily edit the "Controller"). Read this https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

If the ONLY reason to combine the files into one .m file is for version control, there are better ways to do it via github or just changing the version number in the .m file when you make significant changes, and also keep a changes.log file. I don't think it's worth trying to hard-code-edit the GUI View, as that'll require a lot of imagination, manual calculation of ui component positions, etc.

[Mathieu Boudreau]

>If the ONLY reason to combine the files into one .m file is for version control, there are better ways to do it via github or just changing the version number in the .m file when you make significant changes, and also keep a changes.log file.

The issue is, this is a open-source project that's already several years in development, with an ever-increasing team (now 6-10 devs). The problem I've encountered is that occasionally, 2 or more devs will be changing the GUI *.fig files on different branches, and there is no way to merge them to master cleanly. If/when a second dev merges to master, there will be a merge conflict with the fig file, and the only way to resolve it is to chose one or the other.

I was hoping that using *.m files could resolve this issue, but I don't want to give up developing with GUIDE (or App Designer in the future, it's also compiled I believe). I was kinda hoping that since MathWorks implemented an export feature for GUI files, it wouldn't have been to much of an issue to create a reverse functionality (import the file that it can export).

[OCDER]

I see , this changes things a lot. See the new answer. You could go back to .fig from .m via saveas.

[Mathieu Boudreau]

Thank you very much for all your efforts. Unfortunately, I think my real-life use case may be too complex for these workaround, and so I think I'll contact MATLAB to request they add this feature in a future version.

I created a test repository on GitHub (https://github.com/mathieuboudreau/matlab-gui-conversion/) to test this out with real code, and to share with you. A few notes on your suggestion:

• I created a simple GUI using GUIDE with a single button and no changes to the text (https://github.com/mathieuboudreau/matlab-gui-conversion/tree/e99cb0d0ad18e3b917d4aaf50f4f704310e8f35f).
• I then exported it to a single file using MATLAB's GUIDE export tool. (https://github.com/mathieuboudreau/matlab-gui-conversion/tree/4efa292afe0e5e49e77e302fc7e6b0c701b66dcb)
• Trying out your first command using MATLAB R2017a on a Mac OSX 10.12.6

h1 = myGUI_export.m

results in the following error:

Undefined variable "myGUI_export" or class "myGUI_export.m".

I think instead `h1 = myGUI_export` should be called? That command results in an h1 object being saved to my workspace.

• Following this change, the rest of your instructions work for this simple case. I can save the object back to a fig file, and it mimics visually the original file (https://github.com/mathieuboudreau/matlab-gui-conversion/tree/cdefb2f3d3ce46f56e0d80ea6f454f7bdd519422).

The challenge happens when you have a more complex/real case. The one I tested is where I have non-GUI functions within the original *.m files that are used for the software (e.g. handling limits for the GUI, customising the behaviour of buttons of figures while the GUI is running, etc.). In this case, the custom code is lost when resaving the exported single *.m GUI file to a *.fig.

• In this second test run (https://github.com/mathieuboudreau/matlab-gui-conversion/tree/7d54114222a026d77ebb0a905ff9c0dacbd45e92), follow the function "foo()" from the file "myGUI_2.m" to "myGUI_2_exported.m" "myGUI_2_re_exported_from_gui.m". It disappears in the final m file. Also note that "myGUI_2_export_resaved.fig" can't be called by itself, as it's missing the accompanying m file. That means that actually all of the callbacks are lost when resaving to the fig as you suggested.

This is much closer to our real-life case in our project (https://github.com/neuropoly/qMRLab). Also note that we have 2 GUI windows, and that I can't run commands while it is running (so I can't save either figs as handles).

But thanks for all your effort nonetheless. I think maybe you'd need a function to re-seperate the single m files to two (the original callback m file + all the other functions to create the fig), and then use your method to convert the fig-only m file to a fig.

[Adam]

Unfortunately I doubt anything new will be added to GUIDE in future since AppDesigner is deemed to be the future for Matlab. I don't think you should have these problems with AppDesigner as the whole GUI is created in a class (similar to how I would do a programmatic GUI) so the WYSIWYG part of it that allows you to move components just translates straight into the code.

I have also encountered the nightmare of having two people edit a .fig file from GUIDE when using a repository and it is not fun at all. We were only a small team sat next to each other though so it wasn't too difficult for us to just ask each other not to edit the GUI whilst one of us was doing it. I'm not sure there are any solutions to this for GUIDE though. I use a mixture of GUIDE GUIs and programmatic ones - the latter are more robust, but less quick to design and change. AppDesigner sends me flying into a rage so I don't use it at the moment until it improves (if it will).

[OCDER]

Yeah, doesn't seem like there's an easy way. Other languages like JAVA will have some sort of XML code for their GUI that can be modified and saved, and thus it's these XML code changes that can be tracked. For matlab GUIDE, there is no feature like this other than a "LayoutFcn". I'm not sure how to manipulate this LayoutFcn separately.

I imagine you'll have to do this.

 1. Convert .m + .fig into a single exported .m file (myGUI.m)
 2. Use the step in Answer to convert a .m to .fig file (myGUI_test.fig)
 3. Make changes to the .fig file via GUIDE
 4. Export GUI into another .m file (myGUI_test_export.m)
 5. Use a separate code to "extract" the new LayoutFcn and 
    callbackFcn from myGUI_test_export.m into the original myGUI.m file. 
    Essentially, you're merging the new changes into the old .m file.

It's a mess...