Hi
I've been experimenting with the Dashboard Button Node </>Class field and I believe it is not working. Particularly when compared to Numeric Noe (ie using same Class). I am using version 2.1.1
Mike
Hi
I've been experimenting with the Dashboard Button Node </>Class field and I believe it is not working. Particularly when compared to Numeric Noe (ie using same Class). I am using version 2.1.1
Mike
It would be hlpful if you were to provide a small example flow showing the issue.
Here you go. A comparison of severla Dashboard nodes. </>Class works for some and not for others.
[
{
"id": "72290b0c67b0612d",
"type": "tab",
"label": "Test Dashboard Widget Class - 2nd Shot",
"disabled": false,
"info": "",
"env": []
},
{
"id": "2e37603198e8e126",
"type": "ui_button",
"z": "72290b0c67b0612d",
"name": "Test Widget Class - Button",
"group": "86dc49dae866b83e",
"order": 8,
"width": 0,
"height": 0,
"passthru": false,
"label": "Test Widget Class - Button",
"tooltip": "",
"color": "",
"bgcolor": "",
"className": "elecraft-button rounded",
"icon": "",
"payload": "",
"payloadType": "str",
"topic": "topic",
"topicType": "str",
"x": 240,
"y": 100,
"wires": [
[]
]
},
{
"id": "f3f391fef185fc2e",
"type": "ui_switch",
"z": "72290b0c67b0612d",
"name": "Test Widget Class - Switch",
"label": "Test Widget Class - Switch",
"tooltip": "",
"group": "86dc49dae866b83e",
"order": 13,
"width": 0,
"height": 0,
"passthru": true,
"decouple": "false",
"topic": "topic",
"topicType": "msg",
"style": "",
"onvalue": "true",
"onvalueType": "bool",
"onicon": "",
"oncolor": "",
"offvalue": "false",
"offvalueType": "bool",
"officon": "",
"offcolor": "",
"animate": false,
"className": "elecraft-button rounded",
"x": 240,
"y": 160,
"wires": [
[]
]
},
{
"id": "132d423493bc822e",
"type": "ui_text_input",
"z": "72290b0c67b0612d",
"name": "Test Widget Class - Text Input",
"label": "Test Widget Class - Text Input",
"tooltip": "",
"group": "86dc49dae866b83e",
"order": 2,
"width": 0,
"height": 0,
"passthru": true,
"mode": "text",
"delay": 300,
"topic": "topic",
"sendOnBlur": true,
"topicType": "msg",
"x": 250,
"y": 240,
"wires": [
[]
]
},
{
"id": "ed9ce3b09d0821a4",
"type": "comment",
"z": "72290b0c67b0612d",
"name": "Notes on Button",
"info": "Adding classes to Node seems enabled (persist after deploy) but do not work",
"x": 500,
"y": 100,
"wires": []
},
{
"id": "18f9efca5c7354ea",
"type": "comment",
"z": "72290b0c67b0612d",
"name": "Notes on Switch",
"info": "Seems to work",
"x": 500,
"y": 160,
"wires": []
},
{
"id": "4925cc7598a55660",
"type": "comment",
"z": "72290b0c67b0612d",
"name": "Notes on Text Input",
"info": "Adding classes to Node do not persist (removed by Deploy)",
"x": 510,
"y": 240,
"wires": []
},
{
"id": "d4fc08045a7e9641",
"type": "ui_dropdown",
"z": "72290b0c67b0612d",
"name": "Test Widget Class - Dropdown",
"label": "Test Widget Class - Dropdown",
"tooltip": "",
"place": "Select option",
"group": "86dc49dae866b83e",
"order": 3,
"width": 0,
"height": 0,
"passthru": true,
"multiple": false,
"options": [
{
"label": "",
"value": "",
"type": "str"
}
],
"payload": "",
"topic": "topic",
"topicType": "msg",
"className": "elecraft-button rounded",
"x": 250,
"y": 320,
"wires": [
[]
]
},
{
"id": "b0d4da6a8deff716",
"type": "comment",
"z": "72290b0c67b0612d",
"name": "Notes on Dropdown",
"info": "Works",
"x": 510,
"y": 320,
"wires": []
},
{
"id": "591a72c420a35b19",
"type": "ui_gauge",
"z": "72290b0c67b0612d",
"name": "Test Widget Class - Gauge",
"group": "86dc49dae866b83e",
"order": 4,
"width": 0,
"height": 0,
"gtype": "gage",
"title": "Test Widget Class - Gauge",
"label": "units",
"format": "{{value}}",
"min": 0,
"max": 10,
"colors": [
"#00b500",
"#e6e600",
"#ca3838"
],
"seg1": "",
"seg2": "",
"className": "elecraft-button rounded",
"x": 240,
"y": 420,
"wires": []
},
{
"id": "1b0ccc64bbe45863",
"type": "comment",
"z": "72290b0c67b0612d",
"name": "Notes on Gauge",
"info": "Works",
"x": 500,
"y": 420,
"wires": []
},
{
"id": "f0f6286cd6db8439",
"type": "ui_chart",
"z": "72290b0c67b0612d",
"name": "Test Widget Class - Chart",
"group": "86dc49dae866b83e",
"order": 5,
"width": 0,
"height": 0,
"label": "Test Widget Class - Chart",
"chartType": "line",
"legend": "false",
"xformat": "HH:mm:ss",
"interpolate": "linear",
"nodata": "",
"dot": false,
"ymin": "",
"ymax": "",
"removeOlder": 1,
"removeOlderPoints": "",
"removeOlderUnit": "3600",
"cutout": 0,
"useOneColor": false,
"useUTC": false,
"colors": [
"#1f77b4",
"#aec7e8",
"#ff7f0e",
"#2ca02c",
"#98df8a",
"#d62728",
"#ff9896",
"#9467bd",
"#c5b0d5"
],
"outputs": 1,
"useDifferentColor": false,
"className": "elecraft-button rounded",
"x": 230,
"y": 520,
"wires": [
[]
]
},
{
"id": "47a29b6bec92fa2a",
"type": "comment",
"z": "72290b0c67b0612d",
"name": "Notes on Chart",
"info": "Works",
"x": 500,
"y": 520,
"wires": []
},
{
"id": "ddc5a46ed02e286b",
"type": "ui_numeric",
"z": "72290b0c67b0612d",
"name": "Test Widget Class - Numeric",
"label": "Test Widget Class - Numeric",
"tooltip": "",
"group": "86dc49dae866b83e",
"order": 6,
"width": 0,
"height": 0,
"wrap": false,
"passthru": true,
"topic": "topic",
"topicType": "msg",
"format": "{{value}}",
"min": 0,
"max": 10,
"step": 1,
"className": "elecraft-button rounded",
"x": 240,
"y": 620,
"wires": [
[]
]
},
{
"id": "d9ef0649900711f7",
"type": "comment",
"z": "72290b0c67b0612d",
"name": "Notes on Numeric",
"info": "Works",
"x": 510,
"y": 620,
"wires": []
},
{
"id": "b4a6b0db7f082f08",
"type": "ui_template",
"z": "72290b0c67b0612d",
"group": "1c67a074.861f4",
"name": "css etc",
"order": 16,
"width": "0",
"height": "0",
"format": "<style>\n .filled { \n height: 100% !important;\n\n padding: 0 !important;\n margin: 0 !important;\n }\n .nr-dashboard-template {\n padding: 0;\n margin: 0;\n }\n .elecraft-button {\n background-color: orange !important;\n }\n .vk1oo-equipment {\n background-color: #333333 !important;\n color:#27AE60 !important;\n font-size: 25px;\n }\n }\n .vk1oo-button {\n background-color: #010105 !important;\n color:#FFFFFF !important;\n }\n \n .rounded {\n border-radius: 12px 12px 12px 12px;\n}\n \n .bigfont {\n font-size: 18px;\n}\n\n .smallfont {\n font-size: 12px;\n}\n \n</style>\n\n<script>\n$('.vibrate').on('click', function() {\n navigator.vibrate(100);\n});\n\nfunction restore_bg(x) {\n $(this).css(\"background-color\", x);\n };\n\n$('.touched').on('mousedown', function() {\n \n var x= $(this).css(\"background-color\");\n $(this).css(\"background-color\", \"yellow\");\n \n setTimeout(restore_bg.bind(this,x),100);\n navigator.vibrate(80);\n });\n \n</script>",
"storeOutMessages": true,
"fwdInMessages": true,
"resendOnRefresh": false,
"templateScope": "global",
"className": "",
"x": 800,
"y": 300,
"wires": [
[]
]
},
{
"id": "e222f3203f01445c",
"type": "ui_spacer",
"z": "72290b0c67b0612d",
"name": "spacer",
"group": "86dc49dae866b83e",
"order": 5,
"width": 1,
"height": 1
},
{
"id": "86dc49dae866b83e",
"type": "ui_group",
"name": "Dashboard Widget Class Examples",
"tab": "8e4884bb.ff1388",
"order": 5,
"disp": true,
"width": "6",
"collapse": false,
"className": "elecraft-button rounded"
},
{
"id": "1c67a074.861f4",
"type": "ui_group",
"name": "Button Example",
"tab": "8e4884bb.ff1388",
"order": 1,
"disp": true,
"width": "6",
"collapse": false
},
{
"id": "8e4884bb.ff1388",
"type": "ui_tab",
"name": "CSS Samples",
"icon": "dashboard",
"order": 10,
"disabled": false,
"hidden": false
}
]
Well there is a difference! In the case of the button, the class is added to 'class' and node-class
while on the switch it is only added to 'class'. I'll look at the others in a bit.
calling @Steve-Mcl ...
I think this is the only one of the standard dashboard widgets which doesn't retain the class.
.rounded
will produce a rounded button too, but it seems to need an extra CSS rule .rounded button
:<style>
.elecraft-button {
background-color: orange;
}
.rounded {
border-radius: 12px;
}
.rounded button {
border-radius: 12px;
}
</style>
@jbudd There is a bug in the ui-button
which I've got a correctionfor and I'm going to do a PR but there is another underlining issue with the 'text-input' and possibly with some others and I'm waiting for some guidance from 'those more knowledgeable than me' before proceeding.
Mike, I've got the code fixed for ui_text_input and a PR (partially done). But if you would like the changes I can give them to you. It's a one line addition the the 'html' and 'js' files for the node. Let me know and I'll tell you how.
As for ui_button things are actullly working but it's complicated. If you look at the node, the </> Class
should probably not have been added since there is already a way of changing the text and background color:
Hi Paul
Thanks for taking a first time poster seriously.
Re Button Node - I think there may be advantage in getting the </>Class to work. Much more flexibility if it can, ie rounded corners, different shaped buttons; not just buttons with different background and colour.
Re Text Input Node, I would appreciate seeing and understanding how to do the fix. And how long is it usually before a patch gets rolled out generally - especially since 2.1.1 just was released?
Cheers Mike
Let me address your points backwards.
Dashboard fixes are not part of the main release, they are released separately - like other nodes. They are a collection of several nodes so an update will happen when Dave(dceejay) decides to release them.
As for fixing the ui_text_input node you can install the version I just patched to check it out
node-red-stop
cd $HOME/.node-red
npm install juggledad/node-red-dashboard
ui_button - you can still make many changes to the buttons, you just have to use different CSS selectors. If you really want to customize them do a search using 'CSS button' and check out some of te treads like
there is a lot of information on the forum,
Hi Paul
Thanks. Ahh. Just read somewhere else that Dashboard is a different environment. So that makes sense.
Did all you suggested and it appears Text Input Node now works.
And thanks for the links, I'd seen the first - and yes have that addiction! And have been experimenting with UI Template as an alternate to Button Node. But still think getting Button Node working the same way as the others with </>Class would be easier. Will wait and see what happens.
Cheers
Mike
Cheers Mike
Node-red 2.1.2 was released this morning, including:
This has resolved the outstanding issues with the TypedInput widget
But TypedInput in the release still does not retain anything entered for Class.
WIll this be merged into 2.1.3?
The dashboard version is not related to the core 2.1.x. We will release it separately when it is fixed.
Hi Paul
I think the TypedInput widget still needs some work.
Using the same flow I sent previously but changing the CSS, to below: TypedInput widget does not pick up color but picks up the rest. By comparison, Numeric Input and Switch widgets pick up all style attributes.
.vk1oo-equip { background-color: #ffffff !important; color:red !important; font-size: 15px; border-radius: 12px 12px 12px 12px; }Cheers
Mike
I seem to have introduced some confusion; the dashboard widget is TextInput, TypedInput is something else entirely.
But the Dashboard release 3.1.0 release notes say "Fix bad class field in text_input. PR #783"
And indeed this css for a class "test" is still not applied to TextInput
.test {
color:red !important;
}
I see that the HTML is different:
[TextInput. Could this be changed to <p class="label" ... > ?]
<label ng-bind-html="me.item.getLabel()" for="input_0">Text Input</label>
[Numeric]
<p class="label" ng-bind-html="me.item.getLabel()">Numeric</p>
Release 3.1.0 doesn't address the Button widget issue.
Hi
That's it, I'm referring to the behaviour of the TextInput widget, being new to Node Red, I assumed that I had named it incorrectly.
I think TextInput should behave the way the other widgets work and respond the same way to classes applied to the </>Class field.
Cheers
Mike
Until another release addresses this, a work-around is
.myclass, .myclass label {
color: red !important;
}
@MikeW Now you have me confused. Your original flow showed problems with the </> Class
option in the ui-button and ui-text-input nodes but now you are mentioning the 'textInputwidget. I'm not sure if @Jbudd jumping in talking about the
TypedInput` widget may have confused you???
The TypedInput
widget is a jQuery widget that can be used when someone is creating a node. It is used in the 'xxxx.html' file. The ui_text_input is a node-red dashboard widget. (This is another case where a term is being overused ('flow' is another example of an overused term)
This is something different from the </> Class
option not being picked up.
This confusion could be resolved by making sure you use the name of the node. i.e. ui_text_input
vrs TypedInput
vrs 'TextInput'
The patch I created does fix some issues with the </> Class
option in the ui_text_input
node but I now see there are more issues. As for the ui_button widget, it has a 'color' and 'background' option in addition to the new </> Class
option and they take precedence ovet the '</> Class' options. I did not attempt a fix for it.
@dceejay @Steve-Mcl
Looking at this again, I think the issue is with (1) how CSS works, (2) how the dashboard creates classes for the page, groups, cards and widgets (3) other options effecting CSS in existing widgets - like the 'color' and background
options in the ui-button widget and (4) the addition of </> Class
option to the dashboard widgets.
I understand the idea of the </> Class
option (I was one of the peoplewanting it) is to provide an easy
way to apply a change to a single instance of a ui-widget, but in some cases, it doesn't create a CSS selector that it specific enough to override other CSS selectors that are created. The dashboard theme options are taking precedence.
For example take the ui_text_input. There are the CSS selectors that apply are applied based on the dashboard theme style. Then there are other selctors that are applied when you start to type in data. However the </> Class
option just uses the selector you enter which is no where nearly specific enough to override all the cases that apply.
I think the option has opened a can of worms that is going to cause users confusing until the dashboard is rewritten. Users who want to change the defaults are still going to have to use a browser inspector's tool to examng each widget they want to effect and write CSS selectors specific enough to address the area tehy want to change. You know, kind of like what they've been doing all along.
The point of adding class
option wasn't to overcome the classes dashboard applies or even to reduce specificity it was to provide a means of setting uniform styling.
An additional side benefit was being able to dynamically set/adjust the class
at runtime.
While yes, the dashboard styles and outer elements mean you have to increase specificity in your CSS (or apply the heavy handed !important
) its still better than having to address all items individually.
For example...
Say you have a dashboard with 10 blue buttons, 10 red buttons, 10 danger labels, 10 warning labels & 10 info labels...
Without the class
to differentiate the blues from the reds or the danger from the warning from the info labels, you would have to write the styles for 50 items (to target them specifically)
With the class
you add red
class to 10 buttons, add blue
to the other 10 buttons (and so on) then simply target them by differentiating them using the class name
This is (kinda) true - you just need to be more specific. For example, these three buttons have a hard coded background of red
however by using the below CSS, I can target every button with a class of .button-error
to "over power" the background style entry
.button-error.nr-dashboard-button button.md-button {
background: rgba(255, 0, 0, 0.5) !important;
color: rgb(30, 0, 0);
}
Lastly, here is a demo i was using to test things when developing the class entry. It demonstrates how multiple items can use the class (for uniformity) and buttons being styled and how one can dynamically set the class of a widget...
Hope that helps?
Hi
Sorry for any confusion. The concerns I raised were with the uni-button and ui-text input nodes. When @Jbudd used the term TypedInout, I thought that was a term used by Node-Red people for the ui-text input node. So I just used it back in response to his email.
I have been doing more experiments from which I conclude that the treatment of the </>Class option in various nodes is inconsistent. ie I agree with your comment, "but I now see there are more issues". And I agree that the specificity issues with CSS will make it hard to use without users checking what happens for all their cases. I am now trying to migrate my nodes to the ui-template node to avoid this grief.
That said, a consistently working </>Class option does make good sense. But as implemented now, it needs to be caveated with warnings.
Mike