View features like in Houdini/Nuke

[rayalez]

Like snap to grid, node colors, netboxes(collapsable), connection types, etc. Would be really cool.

[wdanilo]

@rayalez, first of all, thank you for so many ideas!
These ideas are all interesting, however we need to talk about them a little bit. What benefits do you get by using them, why you want to use them and why you cannot live without them? Answering these questions would allow me better understand the real purpose why you use these solutions and provide you maybe with some alternative propositions that we’ve got planned!

[rayalez]

Well, these are not “must have” ideas, but rather “nice to have”, I wanted to share them with you in case you haven’t considered them. It’s not that I can not live without them, but they are great tools that make large networks easier to organize and understand.

1. Snap to grid makes it easy to neatly align and arrange nodes, making network look beautiful and well organized.

2. Color coding nodes is a convention that makes it easy to find certain nodes, and understand at a glance what they do. It is sorta kinda like syntax highlighting for visual programming.

3. Netboxes allow you to put together and label nodes with similar purpose(LogoBody in the image above). I don’t use them too often(I usually use subnetworks), but they are an excellent tool to explain what the network does to a person looking at it for the first time.

4. On that subject, Houdini also has sticky notes(yellow note in the image), kind of like comments in code, they are not used too often, but you can use them clarify what some nodes do.

5. Different types of lines that connect the nodes make things look much better, clearer, and prevent connections from getting in a way. For example “rounded pipes” are much neater than straight lines:
   

   

6. One more idea - automatic layout hotkey. You press it and it automatically neatly organizes selected nodes.

7. Oh, and one more - I’d much prefer if input and output circles(at the edges of the node editor) would not be fixed, but would be represented as nodes:
   

   
   
   That way when you pan in the node editor, it feels more natural and less confusing, inputs and outputs are moving along with the rest of the nodes.

[wdanilo]

Oh wow, thanks for such great description! Answering the points:

1. We were planning to NOT support snap to grid, rather “snap to nodes near”. So you will not be limited to the grid, but you’ll still have nicely aligned nodes. What do you think about it?

2. Yeah, I was using it in Houdini often. I’m jsut wondering how could it compose with the fact, that we encode types as port colors. I do not want to make here any rainbow effect. Hmm, any ideas?

3. I find netboxes much more restricted version of Houdinis HDA’s if there would be possibility to expand HDA “in place”. In fact we plan to allow you to expand Luna nodes “in place” so you could see the internal of this function instance in a very similar fashion to netbox. However, we would then have real function, which is more powerful - do it solves your issue?

4. We plan to add some limited support for them, however, every functionality in visual Luna has to be represented in code. Thus we are thinking about binding comments in code to sticky notes’like mechanism. Any ideas about how it should behave in code and in graph are very welcome here - its an open topic.

5. We’ve got prepared some awesome nodes redesign that addresses it. Let’s wait for it and discuss it again then!

6. We’ve got it! But its working poorly now. However, we are working on improving it!

7. We’ve got that planned to. In fact there will be some “mix mode” - you will have both of them, but the lines from the sides of the screen will be hidden by default. It will allow you to work with it in a similar fashion to houdini, but will also allow you to very easily sort the ports, rename them etc. Current implementation was the first step to achive it.

Said that, there are many things we can still improve here. If you would like to help us do it, we would be thankful for any help, contribution and will support it as much as we can!

[rayalez]

1. That depends on the implementation, personally I prefer grid, but I’m very new to luna, maybe I’m just biased and want it to work like the tools I’m used to. Having said that, have you used draw.io? I use it often, and snapping to other nodes(shapes) works brilliantly when there’s a few of them, but if there’s a lot of shapes, it quickly gets out of hand. One slightly misalligned node can make it unclear which node you’re snapping to, and mess things up.

2. It’s not a problem in VEX, different input types(string/int/etc) can have different colors, but nodes themselves can be colored. If a node has a background, or a handle, or a title, those can be colored. That’s a design issue, gotta experiment and see what looks better.

3. Wow expanding nodes in place is an AWESOME idea. I love it.

4. Sorry, don’t have much to contribute here at the moment, I’ll think about it.

5. Connection types are probably the biggest issue for me, really looking forward to the redesign!

6. Great, looking forward to it!

I haven’t checked out luna’s codebase yet, I’m a web developer(django/node/react), I’ll need to see if I have the skills to contribute. If I can, maybe I will =)

[nope]

I just want to respond to the talk about commenting and in defense of netboxes because they are something I use all the time. I mainly use them for commenting/documenting the network. The ability to collapse them is a pretty nice convenience but i dont think its their main purpose. They are useful for saying - “this group of nodes over here are doing this certain thing”

Code comments work the exact same way. I suppose you could say that any group of lines of code that serves a purpose should be collapsed into a function and you can comment on the function but i dont think people actually do that. For example im looking at a bunch of code examples here - https://wiki.haskell.org/Example_code - and its a really common pattern, One line of comments explaining the next few lines of code, you dont only comment on functions, and when you are commenting its assumed that the comment pertains to more than the line underneath, but the whole block of code underneath.

netboxes serve the same purpose, they tell you the purpose of a group of nodes, heres an example from houdinis oceanevaluate node-

I think this might be possible to represent visually and in code at the same time if the comment in code has a beginning and end point, but im not sure…

[wdanilo]

I believe that the best netbox counterpart in Luna are just functions “expanded in place”. You can then select some nodes on the stage and using a shortcut “collapse” them into new node and display it in place (so you could see the internal of this node). It will give you almost exact look and feel of netboxes, but will also work on much better foundation (code modularity) than some special comment syntax.There is also a topic to make these netboxes colorful - it’s definitely worth considering and there is already topic about it somewhere.

Do you think it solves this issue?

[wdanilo]

@rayalez

1. Thanks for sharing your thoughts here. We will try to implement something interesting here and would love to ask you for feedback then!
2. Yeah, I know Houdini really well. However we want to keep Luna as clear as possible, so such color mix can harm this “zen”. We have definitely to try it out and create some visual mockups for that. Any help with this (as separate github issue with graphical mockups) is more than welcome!
3. <3

Thank you for your help and support!

[nope]

Yeah I do really like the idea of the functions expanded.

I guess my worry would be that you would end up with a lot of one off functions created just for a specific task.

I dont know haskell at all but im looking at some of the luna source code- https://github.com/luna/luna/blob/master/core/src/Luna/IR/Expr.hs

For example you have

– === Star === –

– === Literals === –

– === Prims === –

To annotate what you are doing in this section of code.

If i was making this in luna then I would have no way of documenting that this group of lines(or nodes) is for a particular task except to make it into a function.

But that is maybe a good thing and maybe that will lead to better code. Im not sure. I mean I wouldnt worry about it yet id get the expanding functions working because that sounds awesome.

[wdanilo]

@nope thank you for such great comment! Youre talking about some very important design decisions here. First of all, creating a lot of small utility functions is good from the perspective of modular code and functional programming in general. You should prefer making even 30 small functions and them use them in your main function than having a main function with 1000 lines of code!

Regarding the comments, Luna does support a comment syntax. You can use either disable comments (# a = b + 1) or doc comments (## This is a doc comment!). You can annotate the code with them. They are not YET displayed in the visual editor, but we will work to make it happen. However, comments serve different purpose than code modularity. While writing Haskell we are using comments very rarely, please refer to our guide “how to write high quality Haskell” here: https://github.com/luna/luna/wiki/Haskell-code-style

Do it make sense to you?

[nope]

Yep that makes sense! thanks for the explanation.