App Designer Issues and Suggestions

UPDATE (4/16/21, R2021a)

R2021a seems to have resolved many of the issues (discussed below) I had with stability and usability of App Designer, and overall I find using it to be a lot more enjoyable. I especially appreciate the ability to render LaTeX expressions in GUI text. Thanks, MathWorks!

Initial Post (5/25/20, R2019a)

After having used App Designer for several hundred hours (in R2019a), there are a number of issues that I think should be highlighted for future improvement (I looked through the R2020 release notes, and did not see any comments on App Designer at all). Without further ado, my suggestions are:

Bring the functionality of the App Designer editor closer to that of the base MATLAB editor. For instance, in R2019 App Designer, there is no way to automatically fold all functions ('ctrl + =' doesn't seem to work here)--this is especially vexing given how all the callbacks are required to go in the same file (so, in the place where automated code folding is most needed, it is unavailable).

Upon edits to variable names, 'shift + enter' to update the corresponding variables within a function is not available in App Designer either.

Little changes like this aren't a huge deal, but they have meant that for me I often edit in MATLAB's base editor and then copy to avoid dealing with App Designer's editor all together.

Allow certain uneditable portions of the code to be edited. This isn't too much of a dealbreaker for me, but for large multi-directory projects this can be a problem because you cannot perform any path management before createComponents(app) runs. There are ways around this, but it would just be easier to add an 'addpath()' command in the (currently) uneditable code.

Related to this, I wish that you would not make .mlapp files binaries. Given that everything needed to construct the app is contained in the text itself, these should be text files, and clearly the only reason that they are not is to prevent people from editing portions of the code that they frankly ought to be allowed to edit. My concern here, however, is that as long as these are binaries, there is always a risk that some error causes the whole file to corrupt. I ran into an issue the other day where both createComponents(app) and startupFcn(app) would run without errors, but nothing would display. If that had been due to problems with the user-uneditable code, I would have lost several revisions of work.

Make the code linter much less agressive. The auto-suggestions can be quite useful, especially with large apps, but in general there are so many popups. Frankly, it's insane.

Too many suggestions. For instance, I try to type "for ... end" and the code recommends I swap out "end" with "endswith", "enddrag", or "enumeration". This wouldn't be so bad except that the AD linter absolutely hates unclosed loops and conditionals.

Code unfolding fun (not really). Don't close a loop or conditional quickly enough (or don't provide an argument or loop index quickly enough) and all the folded code above where you are working expands. Why would anyone think that was a good idea? (Especially given that there is no auto-fold). Even worse than having to re-fold your code once you've completed your conditional/loop, is having to find the conditional/loop to complete it in the first place; whenever the code above where you work unfolds, your window jumps up however many lines unfolded and you lose your place. That is infuriating.

You don't even have the consolation of being able to use the Code Browser (a nice feature, btw) to return to your place if this unfolding happens because if an incomplete loop or conditional exists, MATLAB will be unable to identify individual functions, so you just have to scroll. Obviously, not the end of the wolrd, but by the 10th time per coding session the code jumps 457 lines like this, it is well past exasperating.

Problems with Methods, Properties, etc. When you first try to add methods or properties (public or private) to the code, it puts the "end" statement in the wrong place (or at least it has done this in my case). I've observed this behavior in two separate GUIs.

Then, upon subsequent additions of methods, the linter becomes really obnoxious. (This will take some explaining on my part; bear with me.) All the individual methods should have their "function ... end" statements aligned. However, when you try to add a new function, App Designer's editor will move your cursor to be one tab behind all the other "function ... end" statements. If you try to correct this by pressing tab, it auto-adds a function statement in the incorrect location, so you can only correct this by repeatedly pressing space.

On one occasion, I did not close a function statement fast enough for the linter, and it responded by adding a new public property to the App. (I hope this was a bug? I haven't been able to replicate it since then.)

My overarching point here is, this aggresive linting has got to stop. I'm OK if I make my own mistakes while coding, but I absolutely cannot stand when the editor itself sabotages me as I code, adding functions where I do not want them and did not request them or even going so far as to add a new property. In the case of the latter, that could have easily been a code-breaking bug that took quite a long time to find, if I were not so careful about managing my properties.

[Dominic Jarecki]

Some other bugs I forgot to mention in the post above (I'll update as I remember things):

• The clipboard occasionally ceases to work, preventing you from copying or pasting within an .mlapp file. Oddly enough, this error is localized to a single .mlapp file; for instance, once while editing two GUIs (for a multiwindow app) and a separate file in the standard editor, I could copy between 2/3, but the clipboard was nonfunctional in one of the GUIs. This happens pretty often, at which point the only workaround is to close App Designer and reopen.
• Organizing callbacks causes several errors occasionally: 1. Sometimes, when moving around the callbacks, their location in the code does not match their location in the browser. 2. Trying to move them towards the bottom of the queue will often fail. 3. Occasionally, moving them around after edits will discard all edits in the moved function up to the last save [This is a pretty serious error].
• Also, speaking of organizing callbacks, why can't the Functions and Properties in the Code Browser be moved around in the same way? The lack of parallelism is a little jarring.
• Rarely, the save function itself will fail. Though the save icon will go gray, it will not in fact save. (I was concerned that this might have happened a few minutes earlier while working on the GUI because the save icon was not turning blue following edits, so I made sure to click 'save' several times; nonetheless, the GUI lost my recent edits.)

Also, I should point out, this post isn't intended to be a rant; overall I like the App Designer. Definitely some room for improvement to bring it up to snuff with the standard editor though.

[Dominic Jarecki]

An additional bug I've noticed; you can't suppress contextual warning messages in the App Designer editor. (So, adding e.g.:

%#ok<SAGROW>

will not do anything. (Annoyingly, MATLAB will tell you that the warning has been suppressed, and will produce another dialog, offering to fix the line for you by removing the contextual warning suppress comment.)

Also, multi-line tabs occasionally break (similarly to the way the the clipboard breaks) after using the editor for a while.

[Amos]

Apologies in advance - perhaps this should be a separate post. Here goes anyway:

1) Further to Dominic's notes on Code Browser, I note that when selecting a function here (R2022b/macOS), the window is scrolled to contain the function def, but no part of that funciton is highlighted. This means visually reorienting (after autoscroll) and hunting for the function. It's almost easier to <ctrl><f>.

2) Futher to 1., highlighting the function def may also mean (although not necessarily) moving the cursor in the code-window, perhaps undesirably (although this could be reserved for an alt or 2nd click). This raises the issue of the (apparent?) lack of fwd/back navigation in appdesigner, and again, more generally, the lack of commonality with the primary IDE.

Cheers

Answer 1

[Ameer Hamza]

All the improvements suggested in your question are quite useful. I am just adding this answer so that the question does not automatically get deleted before someone from Mathworks notices it.

[Dominic Jarecki]

Thanks! I appreciate it.