<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 10:37 AM, Vance Shipley <span dir="ltr"><<a href="mailto:vances@motivity.ca" target="_blank">vances@motivity.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><p dir="ltr">I have long had an interest in visualizing code and a dream of a visual development environment. I've pretty much concluded that a "visual programming language" is a pipe dream for all but trivial use cases however graphical modeling is obvious.</p><span>
<p dir="ltr"></p></span></div></blockquote><div>The thing that I found to be most difficult to handle with graphical tools is that if automatic layout is not good enough, then storing the layout is making it very difficult to handle merges and rebases. At my current job, we just switched from a graphical modeling tool (for UML-like state machines) to a text-based representation and rendering with GraphViz.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span><p dir="ltr">On May 2, 2016 1:22 PM, "Vlad Dumitrescu" <<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@gmail.com</a>> wrote:<br></p></span><span>
<p dir="ltr">> Going the other way around, an IDE can make usage of tools easier -</p>
</span><p dir="ltr">I had always wanted to finish that project by going the other way, starting with a graphical editor (e.g. dotty(*)) to create the model of a communicating finite state machine in a graphviz file (foo_fsm.dot) with annotations.  Feed that through a utility which created a template gen_fsm behaviour callback module (foo_fsm.erl) with annotations so that it could be read back into .dot for further graphical editing.<br>
</p><p>Another, more generally useful, IDE utility I have always planned is a graphical editor for supervision hierarchies.  I would love to start new Erlang applications on a canvas with a palette of application master, supervisor and worker.  Drag and drop the supervisors, connect them with lines to their children, annotate with the child specifications and init arguments and save it as a template application ready to call application:start(foo).</p></div></blockquote><div>A graphical interface is not the only way to improve this kind of editing. It can be done with a tree view and a form-like interface. Eclipse has for example editors for its configuration files that look like the picture here <a href="https://dl.dropboxusercontent.com/u/2517505/editor1.png">https://dl.dropboxusercontent.com/u/2517505/editor1.png</a>, which is arguably nicer than having to plow through 3-4 files with different formats among which XML is the worst.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><p>These aren't terribly difficult projects, trivial really compared to what ROK is talking about, but yet (AFAIK) they don't exist.  If one was to contemplate doing such a thing I understand that Eclipse has a Graphical Editing Framework (GEF) which may form a good foundation for the graphical editor.  Maybe I'll get around to it someday however it's been on my todo list for 15 years now and yet I still use vim as my "IDE".</p>
</div>
</blockquote></div>Yes, GEF is cool, but it has a quite steep learning curve (which might be added to the steep curve of learning Eclipse, and the relatively steep curve of learning Java, depending on one's current knowledge). </div><div class="gmail_extra"><br></div><div class="gmail_extra">best regards,</div><div class="gmail_extra">Vlad</div><div class="gmail_extra"><br></div></div>