App Designer Issues and Suggestions

29 次查看(过去 30 天)
Dominic Jarecki
Dominic Jarecki 2020-5-25
编辑: Amos 2022-11-10
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.
  3 个评论
Dominic Jarecki
Dominic Jarecki 2020-6-22
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
Amos 2022-11-10
编辑:Amos 2022-11-10
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

请先登录,再进行评论。

回答(1 个)

Ameer Hamza
Ameer Hamza 2020-5-25
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.

类别

Help CenterFile Exchange 中查找有关 Develop Apps Using App Designer 的更多信息

标签

产品


版本

R2019a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by