title: What's the "right" way to organize GUI code?
body: <p>I'm working on a fairly sophisticated GUI program to be deployed with MATLAB Compiler. (There are good reasons MATLAB is being used to build this GUI, that is not the point of this question. I realize GUI-building is not a strong suit for this language.)</p>
  
  <p>There are quite a few ways to share data between functions in a GUI, or even pass data between GUIs within an application:</p>
  
  <ul>
  <li><code>setappdata/getappdata/_____appdata</code> - associate arbitrary data to a handle</li>
  <li><code>guidata</code> - typically used with GUIDE; "store[s] or retrieve[s] GUI data" to a structure of handles</li>
  <li>Apply a <code>set/get</code> operation to the <code>UserData</code> property of a handle object</li>
  <li>Use nested functions within a main function; basically emulates "globally" scoping variables.</li>
  <li>Pass the data back and forth among subfunctions</li>
  </ul>
  
  <p>The structure for my code is not the prettiest. Right now I have the engine segregated from the front-end (good!) but the GUI code is pretty spaghetti-like. Here's a skeleton of an "activity", to borrow Android-speak:</p>
  
  <pre><code>function myGui
  
      fig = figure(...); 
  
      % h is a struct that contains handles to all the ui objects to be instantiated. My convention is to have the first field be the uicontrol type I'm instantiating. See draw_gui nested function
  
      h = struct([]);
  
  
      draw_gui;
      set_callbacks; % Basically a bunch of set(h.(...), 'Callback', @(src, event) callback) calls would occur here
  
      %% DRAW FUNCTIONS
  
      function draw_gui
          h.Panel.Panel1 = uipanel(...
              'Parent', fig, ...
              ...);
  
          h.Panel.Panel2 = uipanel(...
              'Parent', fig, ...
              ...);
  
  
          draw_panel1;
          draw_panel2;
  
          function draw_panel1
               h.Edit.Panel1.thing1 = uicontrol('Parent', h.Panel.Panel1, ...);
          end
          function draw_panel2
               h.Edit.Panel2.thing1 = uicontrol('Parent', h.Panel.Panel2, ...);
          end
  
  
      end
  
      %% CALLBACK FUNCTIONS
      % Setting/getting application data is done by set/getappdata(fig, 'Foo').
  end
  </code></pre>
  
  <p>I have previously-written code where nothing is nested, so I ended up passing <code>h</code> back and forth everywhere (since stuff needed to be redrawn, updated, etc) and <code>setappdata(fig)</code> to store actual data. In any case, I've been keeping one "activity" in a single file, and I'm sure this is going to be a maintenance nightmare in the future. Callbacks are interacting with both application data and graphical handle objects, which I suppose is necessary, but that's preventing a complete segregation of the two "halves" of the code base.</p>
  
  <p>So I'm looking for some organizational/GUI design help here. Namely:</p>
  
  <ul>
  <li>Is there a directory structure I ought to be using to organize? (Callbacks vs drawing functions?)</li>
  <li>What's the "right way" to interact with GUI data and keep it segregated from application data? (When I refer to GUI data I mean <code>set/get</code>ting properties of handle objects).</li>
  <li>How do I avoid putting all these drawing functions into one giant file of thousands of lines and still efficiently pass both application and GUI data back and forth? Is that possible?</li>
  <li>Is there any performance penalty associated with constantly using <code>set/getappdata</code>?</li>
  <li>Is there any structure my back-end code (3 object classes and a bunch of helper functions) should take to make it easier to maintain from a GUI perspective?</li>
  </ul>
  
  <p>I'm not a software engineer by trade, I just know enough to be dangerous, so I'm sure these are fairly basic questions for seasoned GUI developers (in any language). I almost feel like the lack of a GUI design standard in MATLAB (does one exist?) is seriously interfering with my ability to complete this project. This is a MATLAB project that is much more massive than any I've ever undertaken, and I've never had to give much thought to complicated UIs with multiple figure windows, etc., before.</p>