[Feature request] In-place help tooltip/popup

[Lex-DRL]

TLDR

How about adding tooltip popups for node parameters (and, maybe nodes themselves - if you click a new "?" button on them)?

Details

Currently, all the help about ComfyUI is in a form of example workflows.

This is great we have it, but... even node descriptions are there. So if you just want to recall what exactly a specific parameter does, your only choice is to load an example workflow (losing your own in the process), look it up and restore what you've been working on. It's very time-consuming (not even mentioning that you need to manually browse an example image first).
In-place popup would be much better... Besides, it would keep docs within codepase - therefore, it would be easier to keep them in sync with the actual implementation.

[Lex-DRL]

UPD2: This entire comment is irrelevant: see the next comment by @Chaoses-Ib

---

UPD:
We can go further and separate docs from code, while still making them integrated right into the UI.

If there was a system that detects an .md file at specific path and shows it's contents in such popup, it would be more than just an UX improvement. This might take a burden of documentation off the ComfyUI/node authors since even less ML-savvy users could contribute into docs. Because their docs would be available not at some random, undiscoverable repo, but in-place, right within ComfyUI.

Specifics

Imagine there is some kind of naming convention. Let's say, ComfyUI looks into /docs subfolder in it's own repo and within every custom node's, too. If it finds an .md file with a name matching to the node name (i.e., CheckpointLoaderSimple.md), it adds a ? button in a corner of each such node in the graph. When clicked, a popup with parsed/formatted contents of the md file is shown. Maybe, even with images (if it's possible to preserve relative paths). To my knowlege, there shouldn't be any issue with converting MD into HTML.

If there is a second convention on how the sections of the file need to be titled (something alike Google docstring format), ComfyUI can even parse descriptions for each parameter/input and show them in-place on hover (after some adequate delay, like 500ms).

Moreover, some custom nodes (e.g., Impact Pack) reuse the same parameters from the core nodes. They can inherit their descriptions from the core, too (inherit explicitly, with a simple keyword syntax like inherited from "CoreNodeName.parameter_name"). In such case, ComfyUI can even build a full description page at runtime with a simple recursive regex search and replace.

But it would only help devs if such a system will be implemented as a built-in one in ComfyUI core, not as some custom node.

Example file structure

The following seems quite an obvious one to me:

# Node name

Some introductory description of what it does. Doesn't matter how many paragraphs, but expected to be short
(and shouldn't have any titles/headers).

## Parameters

### param_1
param_1 Description. Since It's under it's own title, can be formatted as desired, even with tables,
lists and sub-sections (header 4 and on).
Everything till the next parameter title or till the end of parameters section is considered this param's description.

### param_2
param_2 Description. 

### steps
inherited from "KSampler.steps"

...

## Node inputs

(Just like Parameters, but for the input knobs, which are always expected to be connected and not set directly)

## Whatever other level-2 title
Any additional info shown only in the full popup. More detailed description, example use cases and caveats, etc.
There can be as many additional sections as desired.
The only requirement is that right after parameter/input sections there should be SOME level-2 title,
ending the previous section.
From here on, the rest of the file is presented "as is".

All the sections are optional.

If there was such a system in place, I, personally, would be glad to contribute to docs, while I'm terrified of digging into custom node api. And I bet I'm not the one here.

@comfyanonymous what do maintainers think?

[Chaoses-Ib]

There is actually already an interface for nodes to provide descriptions (node.DESCRIPTION), but the frontend just doesn't make any use of it. You can open http://127.0.0.1:8188/object_info and search for "description" to see them.

[melMass]

This was added in Comfy-Org/ComfyUI_frontend#287