Formatting ui-notification

Dashboard
1

Anyone had any luck in formatting the Dashboard 2 ui-notification overlay?
Using it on a phone with grid size 12x12, the overlay is too wide to be displayed correctly, cutting off the text, and the 'Cancel' - 'Confirm' text would be more intuitive if they were buttons instead of text links.
Dashboard v1.15.0

screen
screen1080Ă—831 36.6 KB

[{"id":"b5f2a639b7d19b66","type":"ui-button","z":"be4568a984cb4685","group":"3037a2992d27ef33","name":"Button 1","label":"Driveway","order":2,"width":"4","height":"1","emulateClick":false,"tooltip":"","color":"","bgcolor":"","className":"","icon":"","iconPosition":"left","payload":"click","payloadType":"str","topic":"button1","topicType":"str","buttonColor":"","textColor":"","iconColor":"","x":320,"y":1760,"wires":[["c4a2394d758d7565"]]},{"id":"c4a2394d758d7565","type":"ui-notification","z":"be4568a984cb4685","ui":"ae3d4aeb3f977a90","position":"top center","colorDefault":true,"color":"#000000","displayTime":"5","showCountdown":true,"outputs":1,"allowDismiss":true,"dismissText":"Cancel","allowConfirm":true,"confirmText":"Confirm","raw":false,"className":"","name":"Confirm","x":480,"y":1760,"wires":[["dc147f8bd7854b78"]]},{"id":"dc147f8bd7854b78","type":"function","z":"be4568a984cb4685","name":"Change status","func":"if (msg.payload == \"confirm_clicked\") {\n    var buttons_status = flow.get('buttons') || \"off\"\n    switch (buttons_status) {\n    case \"on\":\n        node.send({payload: \"off\"})\n        buttons_status = \"off\"\n        break;\n    case \"off\":\n        node.send({payload: \"on\"})\n        buttons_status = \"on\"\n        break;\n    default:\n        node.warn(\"Status not matched!\");\n        break;\n    }\n    flow.set('buttons', buttons_status)\n}\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":660,"y":1760,"wires":[["af7ec95ad0c6445c"]]},{"id":"af7ec95ad0c6445c","type":"change","z":"be4568a984cb4685","name":"Change color","rules":[{"t":"change","p":"payload","pt":"msg","from":"on","fromt":"str","to":"#F44336","tot":"str"},{"t":"change","p":"payload","pt":"msg","from":"off","fromt":"str","to":"#A7FFEB","tot":"str"},{"t":"set","p":"ui_update.buttonColor","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":490,"y":1820,"wires":[["b5f2a639b7d19b66"]]},{"id":"3037a2992d27ef33","type":"ui-group","name":"Lighting","page":"7294756f31e17b81","width":"12","height":"12","order":1,"showTitle":true,"className":"","visible":"true","disabled":"false"},{"id":"ae3d4aeb3f977a90","type":"ui-base","name":"Dashboard","path":"/dashboard","includeClientData":true,"acceptsClientConfig":["ui-notification","ui-control"],"showPathInSidebar":false,"showPageTitle":true,"navigationStyle":"temporary","titleBarStyle":"hidden"},{"id":"7294756f31e17b81","type":"ui-page","name":"Security","ui":"ae3d4aeb3f977a90","path":"/security","icon":"home","layout":"grid","theme":"52ba8a01d6eda628","order":1,"className":"","visible":true,"disabled":false},{"id":"52ba8a01d6eda628","type":"ui-theme","name":"Mobile","colors":{"surface":"#ffffff","primary":"#0094ce","bgPage":"#eeeeee","groupBg":"#ffffff","groupOutline":"#cccccc"},"sizes":{"density":"compact","pagePadding":"12px","groupGap":"12px","groupBorderRadius":"4px","widgetGap":"12px"}}]
2 
.v-snackbar__wrapper{
    min-width: 200px;
}

Can also use media query to apply sizing rules only for small screens and so on

2 Likes
3

If your holidays ever ends and CSS is going upwards again in your priority list, that might be a very useful pull request :innocent:

1 Like
4

That's made the width much better, thanks @hotNipi

screen2
screen21080Ă—516 33.8 KB

It's a long time since I used the original Dashboard, but wasn't the Cancel/Confirm interactions actual buttons, which made it clear that one should be selected.
Also, can't we get rid of the incoming payload message - top left - 'click' in my screenshot, when the ui-notification is used for this purpose?

5

Can you raise an issue for this please @Paul-Reed - this shouldn't be the default behaviour

6

They are buttons, (you can style them with a different color)

Set payload to empty string.

7

Also open to changing this too, feel free to open a (second) issue/feature request

8

Thought they were text links... I did check the documentation for styling, but there's no info there.

I realise that, but maybe the payload is needed further in the flow. In any event shouldn't there be an optional name property, like other UI nodes, so we could enter text instead of showing the payload, so for example we could enter " Please confirm action" (and yes I know I could inject that text as a payload :smirk:)

Will do when I return home.

9

Yep. This is a prime candidate for a typed input to permit either string or msg. IMO but then I feel that way about ALL nodes (I hate having to put change nodes everywhere!). There is an open issue somewhere on dashboard about permitting user choice when it comes to where the payload comes from but I am told there are difficulties implementing this on dashboard.

2 Likes
10

It ends when you tear off the August from calendar... But I'm still nearby :smiley:

3 Likes
11

Issues raised as requested -

1 Like
12

I see the node passes the incoming message through. Is that intentional? I can't see any reason to do that.

13

For me this is currently the (last) confusing part of ui node development for D2.

All properties from the config screen arrive via ´props´ on the frontend, and you can override those values via properties in the ´msg.ui_update´. Everything is nicely stored in the state store. And you have a ´getProperty´ function that contains the logic to return the original or overridden value. That all works like a charm out of the box. Really nice for developers.

However on the other hand there is "the value" of the widget. This is not available on the config screen, but is injected via the ´msg.payload´ and stored in the data store. For simple widgets it is clear what the value is. E.g. for a text-input-ui it is the text value. But for a complex svg drawing? And for the ui-notification it is the displayed text. But if you want both a text content and a title in the notification. Or if you want to have a typedinput on your config screen with a default value, which can alsi be overridden as a dynamic property. In that case you need to start mixing data from the data store and state store, which makes it complex again.

Imho that separate data store for messages makes these things complex.

14

Should the node save any extra properties from the incoming message and attach them to the outgoing? For me this would be useful. For example, I have a flow that builds a message from user input which is to be sent to influxdb, I want to put a Confirm/Cancel notification in, but doing that would lose the additional properties so I have to add additional stuff to save and restore them.

15

Yes agree!

I hit the same thing yesterday whilst trying to re-use one ui-notification node for a number of different inputs, but partly solved it by using msg.topic, which is carried forward from it's input.

I don't find the outputs - confirm_clicked, dismiss_clicked or timeout as a payload are particularly useful, as well as usually needing a switch node thereafter to distinguish between them, and maybe also a change node for the payload msg to be of some value.

Why would we need an output to tell us dismiss_clicked or timeout had occurred?
Struggling to remember, but didn't the original Dashboard ui node only pass an output when 'confirm' had been selected, and then passed through the incoming msg? That would be more useful and workable IMO.

I was tempted to raise an issue for this yesterday, but having already raised 3, I thought better of it... :wink:

16

Since it's Saturday night I thought I'd join the party.

Here is what I requested a few weeks ago. Ui-notification allow pass-through via on-click event

I'm confused about the above convo. Hasn't this been done in the latest revision? I haven't had a chance to try it yet.

17

Nope, what happens now is that we get 2 msg's, the first is the original pass through msg (for some reason?), but when confirm is selected we get a second msg with a payload of confirm_clicked.
Try it yourself & see.

18

With the D1 notification node I don't think there is a timeout return, at least it isn't documented in the help text. I can imagine that could be useful though. The timeout is disabled in the case of OK/Cancel mode with D1, but I don't know why that is the case. It should be up to the user to decide.

With D1, when a button is clicked the text of the button itself is returned, so it is up to the user whether the buttons are ok/cancel or just two independent options, and which button is which. I think there is an argument for keeping this compatibility with D1. The Switch will still generally be necessary, but what it is doing is clearer as it will refer to the button text which will probably be self explanatory. I suppose the node could have three outputs, one for each button and one for timeout, that would remove the requirement for the switch.

A minor issue, the fact that the timeout can be disabled by setting to 0 or blank does not appear to be mentioned in the help text.

19

If the only output was provided when 'confirm' was selected, and it was the payload from the button, there may be no need for a switch or change node.

Couldn't we just have 2 outputs;

  1. passes through the msg from the button, ONLY WHEN and IF the confirm button is selected.

  2. all remaining msg's originating from the notification node itself. ie confirm_clicked, dismiss_clicked & timeout

20

If we were to go to the effort of providing 2 outputs then we might as well provide all three. What is the advantage of just providing the two?