Highlight nodes in search results list

[gregorius]

Hi There,

I really enjoy the search functionality but one thing that irritates me is that I sometimes don't know which node is meant - since I can't remember which node I've already opened.

What I would like is that nodes are highlighted (see blinking border) when I move the mouse over the search result:

This screencast is particularly pertinent because all nodes are called "template" (the connected nodes make the context clear).

To get this working, all I did was add these lines:

div.on("mouseover", function(evt) {
    if ( node.z == RED.workspaces.active() ) {
       RED.view.reveal(node.id)
    }
});

here.

I explicitly don't change workspaces (to avoid confusion) by checking the 'z' property.

Is there general interest in this?

[Sean-McG]

What happens if the search results are on different tabs ?

[gregorius]

Nothing. No highlight, no switching of tabs.

That’s the current behaviour so there’s no change.

Hence this works best in conjunction with flow:current.

[shrickus]

Yes, please!

So does the editor window underneath the search box shift around when a node is revealed that is outside the visible bounds of the viewport? Or worse, it's hidden behind the current Search results list? I find the revealed location to be somewhat random, so that might need some thought, too.

There are several things that would make the search more usable, imo. For instance, how can I search only for nodes that are enabled? I suspect there may be a way, but if I have 10 matches and only 2 are enabled, the disabled nodes should show up dotted in the search results (i.e. the same styling the editor uses), ideally at the end of the list.

Autocomplete for things like type:template would be nice to have, so we don't have to type the entire name.

And if I don't select any filters (e.g. "current flow") showing the ones on the current tab at the top of the search results would be most welcome.

[bakman2]

And perhaps remove the gray overlay as well, not sure what it adds.

[gregorius]

@bakman2

not sure what it adds.

because while the search dialog is open, you can't (and shouldn't) interact with the flow - which makes sense since the search content is a snapshot of your current flow --> changing the flow would invalid that snapshot.

[bakman2]

When clicking off the panel, it should hide it, just like vscode for example.

[gregorius]

@bakman2

When clicking off the panel

??? it does do that

[jbudd]

@gregorius

it does do that

If only all editor popups behaved alike ...

[bakman2]

Thats my point, there is no reason for the gray overlay

[gregorius]

@bakman2

no reason for the gray overlay

I sense a circle starting up here - that was my point: the point of the overlay is that "don't modify the flow, I'm just searching it" - the grey overlay communicates that to the user. else it would be even more confusing.

it's a communication element to the user: you are now searching this flow, you can't modify the flow while searching. fullstop. there isn't a search and modify feature in NR.

And the click-out-and-disappear pattern is used for the editor and other panels, so this is a very Node-RED thing to be doing. Instead of a confirmation: "are you sure you want to exit the search?" dialog.

now: don't come and say "well the editor panel doesn't have a grey overlay when it's open" - no it doesn't but the plugins that aren't usable when the editor is open do! I guess there is a case to be made for removing the grey overly for search if the flow does become interactive (i.e. node highlights)....

I think I just went in a circle ....

EDIT: i guess I was off-base: the edit panel also activates the grey overlay - so it is consistent behaviour. crazy how this never really occurred to me.

[TotallyInformation]

@gregorius

crazy how this never really occurred to me.

Not really, this is how UI's should work! So intuitive that you don't notice.

[Trying_to_learn]

Sorry @gregorius but I am not understanding.

div.on("mouseover", function(evt) {
    if ( node.z == RED.workspaces.active() ) {
       RED.view.reveal(node.id)
    }
});

Is that in the actual node-red/packages/node_modules/@node-red/editor-client/src/js/ui /search.js code - as per the github stuff?

[gregorius]

@Trying_to_learn

code - as per the github stuff?

No it's[1] nowhere near the actually source code, it's basically what I did to get it working - locally.

I'm using it over at Erlang-Red but can't - of course - use it inside Node-RED until someone inserts it there. For it to be inserted there, folks have to like it. For folks to like it, they have to post here in the forum saying "hey I like this, can we have this in Node-RED v5". For folks to post here, they need a keyboard .....

Anyone, this is an RFC - Request For Comment, including the code that is required to implement the feature.

I'm not going to create a pull request because I don't know whether it would get merged or not. In the meantime, I'll continue on using Erlang-Red.

EDIT:

[1]= clarification "it" are the four five lines of code I posted - they aren't in the source code but could be inserted at the point that I link to.

[knolleary]

@gregorius I can't think why we wouldn't chose to do this. A PR would be welcome - happy for this type of thing to slip into the master branch so would get picked up by any future 4.1.x maintenance release as well.

[gregorius]

@knolleary

A PR would be welcome

Reveal node in search results via mouseover

e'Voila!

[Trying_to_learn]

That would be kind of nice as I did mention this in my list of things wanted in the new release.

Suggestions for Node Red 5.0

I may need to put my thinking hat on and look more into that. Thanks.

[dceejay]

Indeed it is there in the v5 beta. (though the orange highlight/flashing is hard to see due to the grey overlay - so will need some tweaking)

[Trying_to_learn]

Just asking...

How hard is it to change the colour?

As a lot of nodes are orange in colour the contrast isn't that good.

So if it was a better colour, it would be easier to see.

(a lot of nodes: Said with tongue in cheek)

[gregorius]

@dceejay

orange highlight/flashing is hard to see

@Trying_to_learn

How hard is it to change the colour?

I would not change a thing - my reasoning being that it is very hard to find something that works in all situations: A single node versus many hundreds, colour: function nodes (orange) or comment node (white).

The current solution is the same as all other highlights, i.e. the blinking border is always used when highlighting nodes. Having two different highlights might be confusing.

Perhaps the grey overlay could be less dark so that the blinking is easy to notice. But again might lead to confusion having two different overlays.