4 ms·

Hi, thank you this is great feed back I obviously need to look at the UX here. You (currently) double click the background to create new nodes. There are reason

Hi, thank you this is great feed back I obviously need to look at the UX here. You (currently) double click the background to create new nodes. There are reasons for this but I may need to rethink it. I will also think again about having input output nodes on the canvas as it does solve some issues. I however prefer the visual metaphor of having them floating at the edge of the screen. I am considering making it zoomable / pan able but in someways I like the restriction on complexity. I want to encourage people to create "sub-graphs" instead of add more nodes. I know its not far from perfect yet but EtcH is designed from the ground up to be a "language" rather than a way to wire together pre-defined nodes. Im glad its those innovative parts that you like :)

ReD_CoDE 6y ago
I know that you want it be as functional as possible Input --> Function/Relation --> Output When you talk about language, do you mean you want to build a "textual/visual" solution? User be able to not only develop visual nodes but also some "simple" textual code define nodes
- tjsdavies 6y ago
  Everything in EtcH will be purely functional which both simplifies things and allows us to create interesting new features. Lots of influence here from languages like Elm There will be no textual solution as the plan is to make that unnecessary. Instead complex functionality should be built up by composing functionality from a just a few core language features operators, map etc... A good library/module solution will be needed. I haven't quite got to that bit yet.