Planned/requested quality of life features

[KennedyRichard]

Hello, I decided to keep a different list of features that is just as important as the main one (#13). The reason is that even though they are important, they are less urgent and contribute to make working on nodezator more comfortable rather than unlocking new possibilities like the main list we just mentioned.

This list is also for your benefit, so we can keep all requested/suggested quality life stuff in a single place. Items from this list will usually not be scheduled but implemented right away whenever the opportunity presents itself.

Implemented:

• ✔ when creating new file, don't require user to supply filename, just create and open new file right away (more on this)

Pending:

• improve wording on some stuff (more on this):
  • "Submit" -> "Ok"
  • ask for a filename instead of a path when creating a new file
• better organization of nodes in the popup menu (more on this)
• After inserting a new node, make sure the new node is the only one selected (more on this)
• file manager-related:

  • BTW, is it really necessary that file dialog always opens in home directory? Wouldn't be current working directory better? Or directory where currently loaded .ndz file is located? Or at least, keep the last used directory between dialog activations, so users don't need to navigate from home to the directory they actually use for the project every time the file dialog opens. (excerpt from discussion comment)

  • better behavior (more on this)
  • specific behavior when nothing is selected (more on this)
  • When double clicking on a filename in the file browser it should be opened (link).
• open the add node popup when dragging an unconnected socket out (more on this)
• remove need to press some buttons twice (more on this)
• after "save as", the new file should be listed among the recent ones (more on this)
• idea of 'soft_max' and 'soft_min' on int float entries (more on this)
• pan the view with middle mouse button (more on this)

[KennedyRichard]

Another idea: for the python exporting form, add a Preview button, so the user can view the generated code without needing to save it.

I don't this is strictly necessary and it is so easy to implement that I don't think it qualify as a feature. This is why I'm adding it here. Though it is not necessary, it is something nice to have.

[nrichards]

* open the add node popup when dragging an unconnected socket out ([more on this](https://discord.com/channels/980193047000272967/980193047461630113/1012814443165528195))

Experimental work in nrichards@ca3b77d pops up the menu.

Concerns

• too broad - opens the "add node" popup when dragging from a connected / unconnected socket in / out
• less useful than hoped - leaves source socket disconnected to any input on the new node

Illustration

nodezator_wip_add_node_mousedrop.mov

Questions

1. Should I next explore changing it, as originally described, so that the feature would work only for a) unconnected and b) socket out?
2. Is there still hope that this would be usable, after this review?
   3. without auto-connection to an input
   4. without, perhaps, restoring a "dangling connection" of a segment to the mouse pointer

[KennedyRichard]

Since I didn't know this feature exist in Blender (or perhaps it didn't exist back in college when I used Blender for a couple of school projects), I never got to use it, but I can see how this feature can speed up the workflow. It seems really really useful.

However, after thinking a bit about this QOL feature, I came to the conclusion that it hides a lot of complexity. It's not a bad thing per se, though, it just means that more factors need to be addressed in order to make the feature really useful. I'll share some of my thoughts below as they address your questions either directly or indirectly.

My thoughts/brief analysis

I believe that the new node created should be connected to the socket from which the connection was dragged, regardless of whether it is an input or output. This is so because both scenarios are useful:

scenario	description
(A) new node provides data	the user drags from an input socket, to its left, in order to create a node to provide data to it
(B) new node receives data	the user drag from an output socket, to its right, in order to create a node to receive the outgoing data

Here's where the complexity starts to show. Let's start from the simpler possibilities, though:

1. In scenario A, a previous connection to the input socket is replaced by the new one, if it exists, since input sockets can only have a single connection;
2. In scenario B, a new connections is created always, regardless of the existence of a previous one, since an output socket can send data through multiple connections;
3. Although it would be a useless action, scenario B must account for the possibility of the user instantiating a node which has no parameters (for instance, the node might represent a call to time.time()), in which case no connection could be established anyway;
4. Both scenarios A and B must account for the possibility of the user instantiating (accidentally) a text block instead (either that or we would have to create a new popup menu that doesn't show the option to instantiate a text block);
5. Creating redirect nodes in both scenarios is easy, since there's only one socket at each side of the node;
6. Creating a data node in scenario A is easy as well, since there's only one output socket to connect with; creating a data node in scenario B is easy as well, won't probably be used, since a data node that receives a connections automatically becomes a redirect node;
7. In general, when the new node has only 01 socket available to connect to the socket from which we dragged, we just have to connect them;

Although these are all simple possibilities one still has to take time to understand the internal structure of each different node that can be instantiated even if there's only one possible socket to connect.

Now, the complex part is when we have more than one possible sockets in the new node to connect to the socket from which we dragged.

In Blender, I assume this is rather easy, because since its node editor is specialized for specific 3D design tasks, it has a finite set of possible types, one of which is associated to each socket. So in Blender you'd just have to check whether the sockets were of the same type, but even this would not be enough, since some types in Blender, although different, can be used interchangeably. For instance, some inputs accept image or color data, although they are different types.

Nodezator has the added complexity of being a generalist node editor based in a programming language, with custom nodes provided by users as they desire. These custom nodes might not only have multiple sockets, but such multiple sockets might each be of any arbitrary and new/custom type, or even be of no type at all if the user simple chooses not to provide type hints. All of this is also related to this requested feature that is also being discussed: #47.

And with this, I conclude my brief analysis. Those are my honest thoughts on the matter. I don't work on Sundays either, but I didn't want to make you wait another day for such brief post.

Have a nice weekend.

Peace

[nrichards]

I see how much bigger this features is than I'd imagined. I enjoyed prototyping the naive version, and I will pause!

More:

This reply is an insightful breakdown - clarifying the goal, and discovering additional problems. I am musing about the various combinations of solutions now.

Aside: I'm unfamiliar with this feature in Blender too. And in my noob-ness, I tried and failed to create a node by dragging out. Yet the feature does exist https://youtu.be/Jk_Kk5yOYvA?t=239 (Scenario A, Possibility 6, data).

Concern: Focusing on this part of the conclusion, in agreement:

more factors need to be addressed in order to make the feature really useful

At this moment, I believe the impact of adding the full feature may destabilize development for other parts of the editor, given the scope of the change and the other features I understand are in development. So I am cooling off on being the contributor of it. Certainly it is "two lines of easy" to make the naive version of the feature work. I wonder if the feature's productivity value to the user would be better generated through other changes.

[KennedyRichard]

Mr. Richards,

I think both your analysis of the big picture and your concern are on point.

This is the kind of feature that has so much ties to other features that it requires the other features to be implemented first or at least at the same time in order to understand the whole picture and ensure the synergy/harmony between the features.

I too think pausing for now is the sensible thing to do, given the scope of the changes and its many requirements.

I just wanted to let you know that even if you had decided to push forward with your changes, even though I think it is not the sensible thing to do, I would not have stopped you. As the creator and maintainer of the project, I don't want to discourage people to play, experiment with the code and even contribute to it in any form.

Of course, it doesn't mean I'm negligent in filtering the quality of the code/contributions that are added to Nodezator. Those are 02 separate things. It just means that rather than prematurely discard people's ideas, I prefer to "walk" alongside them as I share my perspective on things, point out possibilities, obstacles and why I think stuff should be this way or the other.

The "I think" is highlighted to put emphasis on the fact that I'm not sure about everything and what people present/achieve may actually lead to a better solution or perspective on a problem. This is yet another reason not to discourage people.

To balance this with the need to ensure quality contributions to the project, I've actually been working on and planning things to help on both fronts (helping people be more free and daring with their changes and at the same time ensure the quality of the code):

1. A comprehensive and accessible article about Nodezator's source (this is in progress);
2. A design document/specification (I'm still to start working on this);
3. The automated GUI testing feature (the feature per se is almost done, but it should still take some months for it to land in the app).

I'm just saying this to you in order to convey my appreciation and commitment to people like you who are willing to contribute.

The automated GUI testing in particular is a formidable tool to empower people to contribute with confidence, allowing them to know right away when their changes break anything. Here's a small demonstration of a session being replayed just by reproducing recorded inputs (link), in case you are curious.

The article will help people understand the structure of the package and other related useful stuff, so they know where to find things. The design document/specification will help ensure people stay on the same page when it comes to discussions/decisions regarding new features and changes and also help settling related matters. These are all ingredients to a healthy and rich environment for contribution and collaboration.

Of course, IndiePython is just a small and humble community, so I'm taking care not to let too much formality (like the specification mentioned above) slow down progress in the project's development. That's why, above all else, dialogue, cordiality and open-mindedness play an important role in this community. Gladly, you excel at all those qualities.

Thank you again for your initiative and ideas. Keep bringing them and sharing your mind/concerns/constructive criticism. It is all very welcome. And let me know if you need anything else.

Peace

[KennedyRichard]

Croissant user from Discord also suggested adding a new option in the cli interface so new files could be created with node packs loaded on them. You can see the suggestion in this link.

Here's the full text:

i have a new idea.
Now We can start nodezator with file .ndz. what about a start nodezator with nodepack files?
like this:
python -m nodezator -nodepack {path to nodepack}
or this:
python -m nodezator -upload {path to nodepack}
command to create new file .ndz with nodepack. This features is very useful for creation .ndz with nodepacks and don`t upload nodepack every time

Despite the fact that after the user selects a node pack for the first time it gets saved in a list of "known node packs" and can be selected from a dropdown menu, this suggestion still seems desirable, since it would make the cli interface more complete.

Saving this suggestion here for future consideration and implementation.

[KennedyRichard]

Magnetic sockets: make it so the mouse doesn't need to be exactly on top of the socket when dragging a connection to it. Instead, whenever the mouse is close the connection automatically snaps to it. As usual, the connection is only established once the user releases the mouse button.

Popup menu when right-clicking visuals from viewer nodes: whenever the user right-clicks the visualization in a viewer node, a popup menu. The only command that comes to mind is the possibility to save the visual on disk, which is already useful enough, but other commands could be added later as needed.

[KennedyRichard]

The magnetic sockets are already implemented as the "socket proximity detection feature".

Another idea suggested by Clifton B on Bluesky:

my only other suggestion would be an option to allow a two-click operation without requiring dragging. Is that already an option? It really helps with diminished motor skills or when Logitech mouse buttons inevitable start giving out.

This will probably be more useful when the connections can be restricted between sockets of compatible types, this way their automatic connection is more intuitive.