[PR Discussion]Debug default node label text

Core Development
21

well a simple function node can also set node.status... don't need to go the full blockly :slight_smile:

though not sure why you don't think having the indicator under the node all the time wouldn't be sufficient to tell if it was on or not... ?

image

"IF" the blob was there all the time then you know that it's sending to status even if nothing has arrived...
(As Nick points out that is not the way it is today - but it would be a simple change that then gives a distinct indication)

22

I can see the status :slight_smile:

But I don't know if the Debug node is JUST displaying status

Or whether its sending to debug sidebar as well

23

but for those of us who are JS challenged - its the only way from now on :slight_smile:

1 Like
24

Or whether its sending to debug sidebar as well

so it's actually an indicator about the sidebar - not the status ?

25

well... now that you put it that way ..... :slight_smile:

Its about telling the difference between a node that sends to sidebar and a node that doesn't but has status enabled

26

so.... as this is a subtly different requirement... how about this... (not immediately implementable)...

If the sidebar debug is not selected then remove the button from the side of the debug node ?

It would mean a slight change in behaviour in that the status (if enabled) would not be pauseable - though in my mind if you need to pause / study the debug you either want to see more than just the value, or if it's changing slowly no problem, and if changing fast you would want to be able to scroll back so would use full debug anyway.

The button doesn't affect the sending to console log option anyway - that is always on if enabled.

It would also make the debug node look "tidier" without the button if just in status mode :slight_smile:

27

ANYTHING that visually shows that only the status is enabled is fine with me :slight_smile:

However 2 points

  1. If its not immediately implementable then is amount of effort (as it would be core devs who'd have to do it) be worth the benefit?

  2. And realistically, how long would it be before it gets done? :slight_smile:

I feel I was SO close to
image

:slight_smile:

How about this - accept my very little request (pretty please) and lets carry on with the discussion on how to properly indicate stuff on nodes given @dceejay oft stated view that the editor is not a ui :slight_smile:

Simon

28

Not going to rush in a temporary fix when you have an acceptable workaround.

Currently the button doesnā€™t have hide/show method so that is what needs adding. Not hard, just not top of priority list for 0.20, but hey it may get slipped in on a rainy afternoon.

1 Like
29

Just as an aside
I tried changing debug node colour dynamically to see how that worked out but for some reason, everything just goes dark!

    color: function() { 
        if (this.tostatus === true || this.tostatus === "true") {
            return "#87f980";
        } else {
            return "#87a980";
        }
    },
30

The color property must be a string - it does not support being set as a function definition.

1 Like
31

and before you ask... :slight_smile: Now that you can set the name of a node and change it's icon... the colour is the only thing that is static - so is the only easy visual way to tell roughly what type of node it is - so making that dynamic and so losing the overall "readability" of a flow is not something that we want to contemplate.

1 Like
32

After some nights of sleep, I think your suggestion is quite a good one :slight_smile:
With some slight mods....

So keep gray for default as it is now (debug only)
switch to red if multiple options (of the 3 available) are selected
switch to green if only status selected
switch to yellow if only console selected (don't need this myself but why not)

I'm off to see if its within my ability to do a POC :slight_smile:

33

hmm - no.. the status indicator is for indicating status - we would like to keep the colours to tie in with various log levels - so warn = yellow, red = error etc...

34

Didn't know about them :frowning:

35

Just to clarify - are we talking about the same blob of colour?

I'm was talking about this one

image

36

The grey one next to undefined - yes...
and you don't know about them being used for log levels as we haven't got as far as implementing that yet... though it's on the to do list. (as per another recent thread)

37

Attempt No:17 :slight_smile:

Ok - forget sub-scripts, name prefixes, icon changes and any colour changes ............

How about we just don't suppress status text if the button is in disabled state?

i.e If status is selected as an option - just always show it?

:slight_smile:

38

Have you been reading the commit log again ? https://github.com/node-red/node-red/commit/d67f91e7ed2daf1b962fd8838903b18dff34a5ae

1 Like
39

  1. I see you like your little secrets :slight_smile:

  2. I think we are within touching distance of each other but still seperated by that last nanometre :slight_smile:

GIF
GIF.gif764Ɨ235 50.7 KB

Just need the status to update even with button disabled

and

  1. Very minor - I'm thinking (but just thinking) that the grey dot should not be there until a msg has arrived - otherwise we could lose some useful debugging information. If its there at deployment as we can't tell the difference between no message and an empty message?
40

We really are going around in circles. We said a quite few replies ago, that we'd change the node to always show a status indicator if that option was enabled. That ensures a newly deployed debug node with status enabled is clearly shown as a node that shares status.

If it didn't show any status at all until a message arrived, we're back at the beginning of you not being able to tell which nodes do what.