From the "roadmap" section for that project > GUI: fix scrolling for scene view window scrolling I need the scrolling to work out of the box. Some of the user

From the "roadmap" section for that project > GUI: fix scrolling for scene view window scrolling I need the scrolling to work out of the box. Some of the users' diagrams are going to be 10x the size of the examples shown for that framework (if not larger). Also in the issues section: * you can't put a custom context menu for the nodes nw.js (and I assume Electron) provide this by default. * Crash: Attempting to connect an input node into self output node Sorry, that's a showstopper. The application I maintain proudly does not crash when the user tries to do this. And then this one: * Implement QML frontend So... if I'm not leveraging QML, what's my workflow with this framework? Am I coding it in C++? If so, then the speed and ease of developing the frontend doesn't compare to HTML5. Just noticed another showstopper: * https://github.com/paceholder/nodeeditor/issues/63 https://github.com/paceholder/nodeeditor/issues/63 (doesn't currently support HiDPI) I need HiDPI support out of the box. This may all seem secondary to my original statement, which was that Qt works fine until you want to draw certain types of diagrams. While I'm convinced it's possible (and looks to be getting easier in the future), the example you gave isn't fully baked, doesn't have a QML frontend, and doesn't look to be stable. I have no doubt people can and will build more frameworks for Qt as it continues to improve. Meanwhile, however, with HTML5 I can use raw Javascript, or d3, or React, etc. all the way up the ladder to frameworks specifically designed for editing diagrams. All of those will result in diagrams of boxes connected by Bezier curves with performance that scales with the number of DOM elements. And every single one of those options have demos that work in the browsers we're staring at that merely require a keyboard shortcut to study and change the code.