Continue GUI development with MATLAB guide or switch to code?

[wahln]

So far we develop the GUI with MATLAB's guide. The problem is that with the increasing number of branches, the situation might become more and more difficult when changes to the GUI are implemented, since the changed .fig files from different branches can't be merged. A the moment that means whenever a GUI conflict needs to be merged, the following steps are necessary: 1) thoroughly examine the novel/conflicting GUI elements in both branches 2) Solve the conflict by taking a .fig file from one of the branches 3) Merge the *.m file (which at least considers the new callbacks) 4) Manually readd the lost GUI elements from the other branch

As an alternative we could consider exporting the GUI creation code to a *.m file, and add new GUI elements through coding. Advantages:

• GUI is not binary any more and thus better integrates into the git workflow
• (maybe) better control over positioning of elements
• Since Octave starts to implement GUI elements, GUI compability with octave might be possible in near future Disadvantages:
• Coding GUI appearance may take more time than manually fixing every merge

What do you think?

[markbangert]

I think this is a reasonable point to discuss and ideally we would switch to a "GUI programming design solution" the sooner the better. However, I do not see how we should approach this and what time would be needed in order to make this happen. One option would be to put this on the list of @ahamdnish but I figure there are other things which are more important first...

Anybody has deeper insight how the GUI programming of CERR is handled exactly? I figure they do it in that way. Maybe somebody is willing to give a little introduction during one of our next group meetings so we all can have a more informed discussion about this?

[wahln]

So baiscally switching to a programmatic GUI with the guide *.m export works (almost) out of the box. This creates a matRadGUI_export.m and a matRadGUI_export.mat file, where the first contains all calbacks and full creation functions and the second contains some meta information and mainly color data (which could also be easily written directly into the script.

Thus a switch to a programmatic GUI is no problem at all, so the workload considerations are more about future GUI development and enabling octave compability in the future. CERR basically uses a programmatic approach from scratch and modularizes into multiple functions. I think we could also consider modularizing the GUI in a more advanced way (e.g. have a "viewer" class that manages arranging and plotting of the ct/dose view, a class for optimization settings, etc.), but that would be the step on top.

[wahln]

There is also now a Pull Request #295 in which I just exported such a GUI *.m file. However, I think in the long run we then could group the panels and outsource their Layout code in dedicated functions / classes, which would make maintenance more easy and would also enable some kind of testing.

[wahln]

This is now developed on dev_classGUI and should be integrated in the future. Needs some more testing, though.