html formating (v1.4.0)

[ghost]

Hi, thank you for new version. I have a slight issue with some scripts using html as it is shown.

In v1.3.2 (all good) notify-send '<a href="https://time.is/no/Oslo">Time</a><br>' " $(shw)" -t 30000 -u low;

In v1.4.0 (html is shown in notifications)

[tsipinakis]

This is a deliberate change, see #497 (and the linked issue), #399.

The problem is that the notification spec never supported markup in the summary so while clients expect markup support in the body and will escape special characters (<-><) they didn't do that for the summary which resulted in parsing errors.

Moving the link to the body of the notification should fix this.

[ghost]

Thank you for the explaination, however I get no actions on these notifications no more (dmenu: context = ctrl+mod4+space or do_action: middle mouse launch browser) I have set verbosity = debug but unshure if it gets striped or what on packaging as I get no feedback in term.

example (btw notify-send is symlinked to dunstify)

#!/usr/bin/dash
shw() {
    clk=`date +%H:%M`
    dat=`date +"%a  %e  %b"`
    echo "$clk   $dat"
}
notify-send "Time" "\n<a href=https://time.is/no/Oslo>$(shw)</a>" -t 30000 -u low;

[tsipinakis]

You're missing quotes around the url in your example. It works when I properly quote it.

notify-send "Time" "\n<a href=\"https://time.is/no/Oslo\">blah</a>"

Now that's an interesting detail, HTML doesn't necessarily require quotes around the URLs but the notification spec includes quotes when it mentions the supported markup tags.

[ghost]

I pasted a test without url quote, my bad. I did not expect these slashes in url ..ef=\"..lo\" this works. Thank you for your time, I would not have spotted this detail.

[tsipinakis]

Seems like this change affected more users that I'd hoped, I'll keep this as the main issue to throw some ideas out for anyone looking for workarounds.

Current workarounds available with what's in 1.4.0:

• Move any links or necessary markup to the body of the notification instead
• If you need to modify the markup of the summary set up a rule to match that notification and override the format from the dunstrc.

I won't re-enable markup in the summary by default since I do not want to break clients that correctly follow the specification.

In case the above workarounds don't work one idea is to add the ability to override the format setting from notify-send so markup could be added from there. That's a ugly solution but would consider it if there are a lot of cases where the above workarounds don't fit.

Please add a reaction/comment with your usecase if you can't fit your workflow to the points mentioned above. This is for me to gauge whether further changes are needed here.

[meribold]

I have a lot of notifications similar to this:

notify-send $'<small>MPD: now playing</small>\nSong Title'

Is it still possible to get the this kind of formatting in Dunst 1.4.0? I tried to add an empty summary and move everything to the notification body:

notify-send '' $'<small>MPD: now playing</small>\nSong Title'

However, notify-send refuses to use an empty summary. OTOH, dunstify lets me do this:

dunstify '' $'<small>MPD: now playing</small>\nSong Title'

Unfortunately, there is one space character at the very start of the notification. I.e., "MPD: now playing" is slightly indented.

[tsipinakis]

Unfortunately, there is one space character at the very start of the notification

From my tests this seems to depend on the format, for example with <b>%s</b>%b as the format I can't see any indentations but with the default format for example there is an empty line at the start of the notification.

Given that you want a modifier on the entire summary you could add a rule like this.

[mpd]
    summary = "MPD: now playing"
    # or even better appname = mpd with -a mpd in notify-send
    format = "<b><small>%s</small></b>\n%b"

The difference here is that the format declaration is separated from the actual data of the notification. This can be an advantage or disadvantage depending on how you look at it.

As I said I'm open to discussion about adding format as a hint so this can be done directly from notify-send.

[meribold]

I think your suggestion will indeed work for my use case. I don't have any strong opinion about whether it would be nicer to do this with something like

notify-send --hint='string:format:<b><small>%s</small></b>\n%b' ...

Thank you for the suggestion (and your work on Dunst)!

[bebehei]

@tsipinakis Can we unpin this issue? Since it's fixed in 1.4.1 and almost all distros now either ship old 1.3.x or 1.4.1.

[tsipinakis]

It's not fixed, that's a side-effect from #497 which was us going against the spec, for better or for worse I didn't revert that. It wasn't caught until the 1.4.0 release and given the choice between re-introducing a problematic behaviour for all clients and fixing an accidental backwards incompatible change, I chose to hold off.

Honestly, I'm not really satisfied with any of the workarounds offered I'd much prefer it the old way as well, but given that this is not supported by the spec there's not much else that can be done.

Oh, and we should be more careful about changes like this in the future, in retrospect this should have gone through a proper deprecation phase.