pckerneis / webaudio-visual-editor Goto Github PK

Describe the bug
There's an assertion (jassert) in Debug mode when trying to inspect a comment name property with line breaks. The PropertyItemTextComponent's editor isn't set into multiline

To Reproduce
Steps to reproduce the behavior (in Debug mode)

1. Create a comment element (right-click on the graph panel, Add..., Add comment)
2. Type some multi-line text.
3. If you select this comment alone, a jassert is triggered when updating the inspector panel.

Expected behavior
I think the best thing to do would be to allow multi-line text property components. But that would need some visual trickery as the first line of the property's value would begin with the parameter's name label. e.g.

value: "This is a multiline
text looking good"

We would need either to add some 'offset' to the first line of the value's TextEditor, or
having smart connected editors for each line (that sounds heavy for objects that may have thousands of copies for a session) or, the simplest solution (but not as much satisfying) : just add a line break before the value section e.g.

value:
"This is a multiline text
made easy"

Desktop (please complete the following information):

• OS: OSX 10.13.6
• Version: 0.0.1

A menu category should be added in the main menu bar on Windows to add a "Preferences..." menu item as well as "About...".

Chrome and Mozilla accept constructor methods for AudioNodes but Safari is still expecting the factory methods (e.g. AudioContext.createGain() etc...). There should be an option in the app preferences to determine wether we should use the factory or the constructor methods.

I'd like more in-app documentation in various forms.

• The only one implemented today is the tips for Message elements (a popup-up filtered list of methods accessible is shown when the message's editor is used).
• There should be a description of WebAudio elements such as nodes, contexts, buffer... It could be a tip window in the LibraryPanel or maybe a footer bar (but it'd be a small space for potentially long texts).
• There should be a documentation panel. It can be based on JUCE's WebBrowserComponent to show HTML doc. Quick access to topics should be possible (something like "Show in documentation" in graph elements popup menu).
• Auto-completion/validation in the code editors is too ambitious for now. It'd require to actually interpret the JS code.