Tooltips on nodes

[GrimPixel]

There can be a tooltip on the node, to remind the user of the conditions of using the node, like the denominator shouldn't be zero.

[KennedyRichard]

Tooltips are a great idea. I just didn't implement them yet because of other higher priority features.

The only thing to be decided is which elements should have tooltips and what would be the info on the tooltips and in which context. There's a lot of elements on the app, a lot of different contexts and a lot of relevant info about the elements that could be shown in the tooltips, so it is something that requires planning.

However, considering the example you gave...

to remind the user of the conditions of using the node, like the denominator shouldn't be zero.

...there is already a feature available for this purpose.

Since this kind of info is related to the underlying callable the node represents, it should be included in the node's docstring.

Then, anyone that wants to know about the node can then just select the node and press Shift+i, or right-click the node and select the command View main callable info. The source of the callable (or other relevant info) is then shown in a text viewer, properly syntax-highlighted. There the user will be able to see your function and its docstring containing all relevant info you desire.

This is also how we do things in text-based Python as well, we just inspect a function's docstring by passing it to help().

I can see how this kind of information could be useful as a tooltip, like you mentioned, but the problem is the volume of information. It is just too much stuff to shown in a tooltip.

Try, for instance, to grab information on json.loads, by importing it and running help(json.loads). It is just too much information, and yet, it is all relevant in order to know which parameters are available and what each of them means. It doesn't fit a tooltip suitably, though. That's why we store this info in the docstring, and the users can inspect it whenever they want to know about a node.

---

Changing topics a bit, I'd like to thank you, GrimPixel for your patience in waiting for my answers and for the continuous feedback. I've been focusing my time recently in finishing the changes for the release of the new version, which is why I didn't answer all your previous posts yet, but I'll keep answering them one by one whenever I find time between my tasks until everything is answered. And feel free to keep the questions, suggestions, feedback and concerns coming.

As I said this is all much appreciated and you have my thanks for this. Discussions contribute to increase the quality of the software over time as much as the development work itself, because while development work causes the app to advance in its path to its ideal state, discussions work like a compass to help us determine which paths we must take to reach that destination.

Peace

[KennedyRichard]

Just complementing my answer, note that there's another variation of the Shift+i command, which is just pressing i.

Shift+i triggers the View main callable info command, which, as I said, causes info about the callable to be shown (source, help text, etc.).

i however, triggers the View node info command, which is slightly different, and shows the source of the node script entirely (not just the source of the callable, but the source of the entire file, that is, so that you can see what code surrounds your callable like import statements, variables, etc.).

Though they look very similar there's a very simple reason they both exist: it is because the callable isn't always defined in the node script.

For instance, if I wanted to turn math.sqrt into a node, this is what the node script would look like:

### turning callable from standard library into a node

### import callable
from math import sqrt

### alias it as the main callable
main_callable = sqrt

### define the standard library import statement
stlib_import_text = 'from math import sqrt'

Executing the View node script command on the node would just show us the code above, the node script. However, it tell us nothing about the callable itself, which is math.sqrt. That is why View node script isn't always enough. When the callable is grabbed from elsewhere we need the View main callable info command to learn more about the callable itself.

Neither command is absolutely better than the other. Depending on the node, one might be more useful than the other.

[GrimPixel]

Thank you for your words. Soft fire makes sweet malt.

There are an operation manual and a safety sign for a machine, in which the safety sign is placed at an obvious place and not the other. This is what I think should be shown on a tooltip. Those who create node decides what the most important is to show on the tooltips. It could be the first lines below def.

[KennedyRichard]

It could be the first lines below def.

That's an interesting idea. I'll keep that in mind, but for now I think it is too soon to think about tooltips as there are other features of higher priority to be implemented. And, as I said before, nodes have too much info so we need to think carefully about which info we'd choose for the tooltips.